On 27/05/15 04:08 PM, Bob Proulx wrote:
Deb wrote:
I'm intimidated by the bug reporting system and kind of afraid to use it,
but I'll read up on it thoroughly and see whether I can file a bug report
without getting yelled at (or filing a duplicate by mistake).
LOL! I have been yelled at in so many bug reports that I am
desensitized to it. I rather expect that every time I file a report
that I am going to get griped at for it. So I sympathize. I have
stopped filing reports against some packages due to this. But that
shouldn't stop people from doing so when it is the right thing to do.
But I completely understand if you want to avoid the conflict. In
which case discussing the issues here will motivate someone (perhaps
even me) to file a bug about it. I have cruft installed but I don't
run it. It is one of those grand experiments that is perpetually in
development that doesn't seem to have been finished off yet. I would
hope that someone who actually uses and likes cruft would jump in and
help with it.
It should anyway be reported as a bug only if it's really a bug and not
just some oddity of my own install. That would mean other people having
to reproduce it. Hopefully someone who is reading this will do so.
I just reinstalled that library as per your instructions and plan to rerun
cruft when I have time to check whether it still gives me the same missing
dpkg. I"m betting it won't.
I should have also mentioned this in my message. Let me mention it now.
# apt-mark markauto libept1.4.12
Normally libraries are installed as dependencies of other packages.
But if you install any package manually that package will be marked as
manually installed. By installing that library manually it was marked
as manually installed. Meaning that it would never be a candidate for
"autoremove" cleaning later. In order to keep the system tidy (and
you are running cruft so I know you care about keeping it tidy) it
should be marked as "auto" again.
Jessie complained that the "markauto" option is deprecated and I should
use apt-mark auto instead. So I did and was informed that the library
package was already marked auto.
If you wish to review the list you can list all of the manually
installed packages and all of the automatically installed packages.
They are long lists so I suggest browsing them with the 'less' screen
pager.
$ apt-mark showmanual | less
$ apt-mark showauto | less
Okay, this is bizarre. The first command shows that apt, bash, whiptail
and a whole bunch of other packages that were installed by the
netinstaller are marked manual. In total there are 263 manual packages
on my system.
There are 1,048 auto packages listed, including nearly all lib*
packages. I'm thinking that Jessie must be configured to mark lib*
packages as auto even if the parent package install is manual.
Python 3 and python3.4 are listed under auto, but python 2.7 is listed
under manual even though the OS still depends more heavily on 2.7 than
on 3 or 3.4.
The only package I've installed through curl and make rather than
apt-get, and the only package that isn't from the Jessie main
repository, is valgrind3.10.1. It is listed under neither manual nor
auto, but ir runs perfectly.
I'm putting off installing etckeeper until I can find out whether it
will mess with my version of valgrind, which is later than the Jessie
main repository version.
Thanks again for all your help.
Deb
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55664b29.8060...@gmx.com
