Chris Hofstaedtler wrote... > You are welcome to write a new tool or implement all the missing > parts in deborphan and deal with users thinking deborphan is a magic > tool that knows everything and its output can be used by > non-thinking humans. Various people in the past have suggested its > "trivial" and "obvious" how it should work, yet we don't seem to > have a lot of these tools that are not "partially right but also > wrong a lot".
That's not my point.
When we remove a package from Debian, we create a situation where
users lose a feature, and it is our task to keep the inconvenience
low.
For many packages we don't even have to care - packages with an
embedded version number like libraries or python have a natural
replacement, and in general it's drawn in automatically. Packages that
no longer work (dropped kernel feature, retired API usage), well, too
bad. Packages with a low popcon count, two digits at most, tell, too
bad as well.
Packages like deborphan (popcon high four digits) fall in neither
category. Users want it, big scale. So If you think is no longer good
for the job - I trust your judgement - the remaining task is to provide
users guidance how they get this job done in the future. And that should
be part of the initial RM request without being asked for.
You pointed to the release notes. The two methods suggested there fail
miserably: On an unstable chroot here, not updated without a week, so
before the beginning of the t64 transition, deborphan reports:
# deborphan
libb2-1
libcanberra0
libhiredis0.14
liblua5.2-0
libmpdec3
libnewt0.52
libpcre3
libsigsegv2
Which alternative tool provides this list?
The suggested alternative "apt list" - note I have to enhance the
expression since my internal distribtion is okay as well:
# apt list '?narrow(?installed, ?not(?or(?origin(Debian),?origin(local))))'
Listing... Done
#
So, nope. Also, 38 times slower.
The suggested "apt-forktracker" seems to do the same thing as the "apt
list" command, without being extensible for other origins. So, nope.
Also, 56 times slower.
Perhaps it can be done using debfoster, but that requires some
configuration which I didn't understand in a quick test.
The last thing I found was "apt list '?garbage'" - but this lists more
packages, and I fail to see the difference. Also, 38 times slower.
This is the kind of research users of deborphan will have to to,
or they look into the net, and will possibly not get the best adivce.
My objections against removing deborphan are mostly nostalgic ones as it
served me well for more than 20 years. Quite frankly, not a real point.
So, I can live without deborphan - if it was let go with dignity. Which
means I can have a different tool that serves the purpose, being telling
me which packages can be removed from the system because they are just
cruft from old times.
My point is solely about not giving users good advice how the get
deborphan's job done. And not giving it in the first place.
Christoph
signature.asc
Description: PGP signature
