Bug#1065312: RM: deborphan -- ROM; missing too many dpkg features, thus broken and unreliable

[Andres Salomon]

On Sun, 10 Mar 2024 15:27:21 + Scott Kitterman 
 wrote:



On March 10, 2024 3:23:32 PM UTC, "Martin-Éric Racine" 
 wrote:
>On Sat, 2 Mar 2024 18:40:13 +0100 Chris Hofstaedtler  wrote:
>> * Christoph Biedl  [240302 17:02]:
>> > Chris Hofstaedtler wrote...
>> >
>> > > please remove deborphan. It is stuck, featurewise, in a very old time
>> > > and does not support many currently available dpkg features properly
>> > > (multi-arch, versioned provides, etc).
>> >
>> > FWIW, deborphan is part of my regular workflow, and while you claim
>> > it has defects, it works for me pretty well.
>>
>> It works "well" if you use it in very limited usecases, yes (like I
>> did). It doesn't seem to work well for a lot of people using more of
>> the "features" it has.
>
>Just because it doesn't work for everyone is not a remotely good
>enough reason to ask for its removal. It works for most people. don't
>break it for them.
>
>> The t64 transition will apparently make deborphan mostly useless in
>> trixie.
>>
>> > [..]
>> > So: What are the alternatives? How do they work? Are they a drop-in
>> > replacment or do they introduce new dependencies? Are there feature that
>> > will be no longer supported?
>>
>> release-notes recommends:
>> 
https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#removing-non-debian-packages
>
>Which has nothing to do with what was asked.
>
>> Some people seem to recommend debfoster.
>
>Which really doesn't provide similar functionality.
>
>> > Leaving users in the void about this is just bad style.
>
>I totally agree. Not wanting to maintain it is a shitty reason for
>asking for its removal. If you don't wanna maintain is, just orphan
>it.


It's really a maintainer call if that's appropriate.  So far no one has jumped 
up to ask if they can take over the package.



I'd take the package. I'm one of those who've been using deborphan for 
20+ years and was very surprised to find it gone. If it's truly too 
buggy to consider trustworthy, I'll change the code to spit out a 
warning to users about that. I suspect most deborphan users are grizzled 
oldsters who know better than to blindly trust its recommendations anyway.


OpenPGP_0x645D0247C36E7637.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1065312: RM: deborphan -- ROM; missing too many dpkg features, thus broken and unreliable

[satanic . surfer . 666]

One addition, it seems Synaptic is internally also using deborphan:

https://github.com/mvo5/synaptic/blob/0.91.3/common/raptoptions.cc#L202-L230

and the removal of deborphan seems to break this integration as well.

Bug#1065312: RM: deborphan -- ROM; missing too many dpkg features, thus broken and unreliable

[satanic . surfer . 666]

Hello everyone,

just adding the following from a user-perspective:

I was quite surprised that a tool i'm using since two decades and on a
nearly weekly base is getting suddenly removed from Debian.

And when looking at the title of the relevant bug report of the removal
to notice a "broken and unreliable" while that tool is neither broken
nor unreliable for the use cases i'm using it (i have no idea what the
previous mentioned "limited usecases" means and if that is the case for me).

I would be very grateful if this decision is revisited and as long as
this tool is actually not broken and is doing what it should for it's
user base to keep it available until a drop-in replacement* has been
found and/or communicated.

And if "debfoster" is a 1to1 alternative to deborphan what about
providing some kind of metapackage with a readme on the reasons /
transition to that debfoster package so that users are not left in the
dark what to choose instead?

* Drop-in replacement in the meaning that i don't need to figure out
some regex calls passed to "apt" or similar.

Disclaimer: As already mentioned previously this is not about dropping
the package in general, but providing at least *some* visible/public
guidance for users of such a popular package so that it's user base is
not left in the dark.

Bug#1065312: RM: deborphan -- ROM; missing too many dpkg features, thus broken and unreliable

[Vincent Lefevre]

On 2024-04-17 01:39:48 +0200, Vincent Lefevre wrote:
> On 2024-03-11 15:18:44 +0100, Chris Hofstaedtler wrote:
> > Thus, a good approximation of the default deborphan functionality
> > (no additional options passed) is:
> > 
> > $ apt-mark auto '~i !~M 
> > (~slibs|~soldlibs|~slibdevel|~sintrospection|~sdebug)'
> > possibly followed by
> 
> No, to mimic deborphan, you should exclude ~slibdevel and ~sdebug
> from this list. So
> 
>   apt-mark auto '~i !~M (~slibs|~soldlibs|~sintrospection)'
[...]

I forgot: deborphan also had other rules. Something useful is that
it could detect dummy / transitional packages. It seems that apt
patterns cannot work on the package description.

https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html

recommends "Also, it is recommended to adjust its section to oldlibs
and its priority to optional in order to ease deborphan's job." but
this is not always done (this was not absolutely necessary for
deborphan, which could also look at the package descrption, but
for apt-mark, this is now a must).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1065312: RM: deborphan -- ROM; missing too many dpkg features, thus broken and unreliable

[Vincent Lefevre]

On 2024-03-11 15:18:44 +0100, Chris Hofstaedtler wrote:
> Thus, a good approximation of the default deborphan functionality
> (no additional options passed) is:
> 
> $ apt-mark auto '~i !~M (~slibs|~soldlibs|~slibdevel|~sintrospection|~sdebug)'
> possibly followed by

No, to mimic deborphan, you should exclude ~slibdevel and ~sdebug
from this list. So

  apt-mark auto '~i !~M (~slibs|~soldlibs|~sintrospection)'

Let's recall the deborphan(1) man page:

  The default operation is to search within the libs, oldlibs and
  ^^^
  introspection sections to hunt down unused libraries.
  ^

Indeed, -dev packages are necessary to do development work on
non-Debian software (or just build such software); so, if such
packages have been manually installed, they must probably remain
installed and not be marked as auto.

Similarly, -dbgsym packages are typically installed by the user for
debugging purpose. However, such packages should be removed when
the associated library package would be removed if the -dbgsym
package were not there, but the above pattern will not catch that.
This was already an issue with deborphan:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742196

On 2024-03-17 15:54:27 +0200, Martin-Éric Racine wrote:
> Another issue I've run into to try and replace deborphan with some
> apt-mark recipe: apt-mark's regex syntax is not documented. The man
> page merely lists the commands and options available.

I suspect that this is apt-patterns(7). The apt-mark(8) man page just
gives a reference to apt-get(8), which mentions apt-patterns(7), but
I think that a more direct reference should be given.

> For instance, I have no idea how you came up with the above regex
> recipe, or how I would tell apt-mark to never mark as "auto" anything
> with a priority important or higher.

I don't think that you should care of the priority. This was needed
for deborphan in order to ignore the "required" priority, but AFAIK,
apt will never propose to remove such packages.

The only thing that is missing with patterns is to be able to specify
a package list from a file, in order to mimic deborphan's keep-list:
/var/lib/deborphan/keep

But one could still write a simple wrapper to add "!?name(package_name)"
to the pattern for each package_name found in a keep-list file. It could
even be possible to provide regular expressions, which deborphan did not
support. For instance you could have a pattern_file file with

  ~i !~M (~slibs|~soldlibs|~sintrospection) !~n(pkg1|pkg2|pkg3)

and use

  apt-mark auto "$(cat /path/to/pattern_file)"

Before doing that, you could check with

  apt-mark showmanual "$(cat /path/to/pattern_file)"

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1065312: RM: deborphan -- ROM; missing too many dpkg features, thus broken and unreliable

[Martin-Éric Racine]

On Tue, 12 Mar 2024 10:22:25 +0200
=?UTF-8?Q?Martin=2D=C3=89ric_Racine?= 
wrote:
> On Mon, 11 Mar 2024 15:18:44 +0100 Chris Hofstaedtler  wrote:
> > On Sat, Mar 02, 2024 at 03:16:22PM +0100, Chris Hofstaedtler wrote:
> > > Given the C codebase and lack of any patches so far I do not see that
> > > deborphan will ever get these features, and we have other tools
> > > available that work, do not mess with dpkg internals and are actually
> > > maintained.
> >
> > As people have asked so nicely, and not at all demanding, entitled
> > or otherwise bossy in this bug report, I've checked around a bit how
> > APT provides deborphan's functionality today.
> >
> > As you all know, apt keeps track of when a package was installed
> > manually or automatically. This is mostly equivalent to manually
> > maintaining a deborphan keep file, but automated. apt-mark can be
> > used to manipulate the manually-installed state.
> >
> > On top of that, apt-patterns(7) documents how to select packages,
> > including on sections, installed status, manually-installed status.
> > It can also used to select based on package names and regexes.
> >
> > Thus, a good approximation of the default deborphan functionality
> > (no additional options passed) is:
> >
> > $ apt-mark auto '~i !~M 
> > (~slibs|~soldlibs|~slibdevel|~sintrospection|~sdebug)'
> > possibly followed by
> > $ apt autoremove
> >
> > If you're using --guess- or --guess-section with
> > deborphan, you can copy the regex lists from deborphans source. A
> > lot of them are however outdated and wrong, so you were already in
> > "living dangerously" territory there.
> >
> > And that's it. deborphan does not do any magic and you can do all of
> > it with apt.
>
> Thanks for making the effort to investigate possible substitutes.
>
> However, those are all approximations, not a direct substitute. All of
> these methods essentially require whitelisting, blacklisting or
> auto-marking packages for future processing. Meanwhile, deborphan
> makes good guesses on the fly. Yes, its methods are kinda outdated,
> its misses support for some of the recent dpkg bells and whistles, but
> it still does a good enough job for most cases, as attested by its
> popularity contest rating just below 10k.
>
> Sorry, I really think that the correct action is to orphan the
> package, not remove it.

Another issue I've run into to try and replace deborphan with some
apt-mark recipe: apt-mark's regex syntax is not documented. The man
page merely lists the commands and options available.

For instance, I have no idea how you came up with the above regex
recipe, or how I would tell apt-mark to never mark as "auto" anything
with a priority important or higher. At best, I can tell that whatever
follows each |s lists in the above recipe is a Debian repository
section.

Martin-Éric

Bug#1065312: RM: deborphan -- ROM; missing too many dpkg features, thus broken and unreliable

[Martin-Éric Racine]

On Mon, 11 Mar 2024 15:18:44 +0100 Chris Hofstaedtler  wrote:
> On Sat, Mar 02, 2024 at 03:16:22PM +0100, Chris Hofstaedtler wrote:
> > Given the C codebase and lack of any patches so far I do not see that
> > deborphan will ever get these features, and we have other tools
> > available that work, do not mess with dpkg internals and are actually
> > maintained.
>
> As people have asked so nicely, and not at all demanding, entitled
> or otherwise bossy in this bug report, I've checked around a bit how
> APT provides deborphan's functionality today.
>
> As you all know, apt keeps track of when a package was installed
> manually or automatically. This is mostly equivalent to manually
> maintaining a deborphan keep file, but automated. apt-mark can be
> used to manipulate the manually-installed state.
>
> On top of that, apt-patterns(7) documents how to select packages,
> including on sections, installed status, manually-installed status.
> It can also used to select based on package names and regexes.
>
> Thus, a good approximation of the default deborphan functionality
> (no additional options passed) is:
>
> $ apt-mark auto '~i !~M (~slibs|~soldlibs|~slibdevel|~sintrospection|~sdebug)'
> possibly followed by
> $ apt autoremove
>
> If you're using --guess- or --guess-section with
> deborphan, you can copy the regex lists from deborphans source. A
> lot of them are however outdated and wrong, so you were already in
> "living dangerously" territory there.
>
> And that's it. deborphan does not do any magic and you can do all of
> it with apt.

Thanks for making the effort to investigate possible substitutes.

However, those are all approximations, not a direct substitute. All of
these methods essentially require whitelisting, blacklisting or
auto-marking packages for future processing. Meanwhile, deborphan
makes good guesses on the fly. Yes, its methods are kinda outdated,
its misses support for some of the recent dpkg bells and whistles, but
it still does a good enough job for most cases, as attested by its
popularity contest rating just below 10k.

Sorry, I really think that the correct action is to orphan the
package, not remove it.

Martin-Éric

Bug#1065312: Re: Bug#1065312: RM: deborphan -- ROM; missing too many dpkg features, thus broken and unreliable

[Martin-Éric Racine]

On Sun, 10 Mar 2024 15:27:21 + Scott Kitterman  wrote:
>
>
> On March 10, 2024 3:23:32 PM UTC, "Martin-Éric Racine" 
>  wrote:
> >On Sat, 2 Mar 2024 18:40:13 +0100 Chris Hofstaedtler  wrote:
> >> * Christoph Biedl  [240302 17:02]:
> >> > Chris Hofstaedtler wrote...
> >> >
> >> > > please remove deborphan. It is stuck, featurewise, in a very old time
> >> > > and does not support many currently available dpkg features properly
> >> > > (multi-arch, versioned provides, etc).
> >> >
> >> > FWIW, deborphan is part of my regular workflow, and while you claim
> >> > it has defects, it works for me pretty well.
> >>
> >> It works "well" if you use it in very limited usecases, yes (like I
> >> did). It doesn't seem to work well for a lot of people using more of
> >> the "features" it has.
> >
> >Just because it doesn't work for everyone is not a remotely good
> >enough reason to ask for its removal. It works for most people. don't
> >break it for them.
> >
> >> The t64 transition will apparently make deborphan mostly useless in
> >> trixie.
> >>
> >> > [..]
> >> > So: What are the alternatives? How do they work? Are they a drop-in
> >> > replacment or do they introduce new dependencies? Are there feature that
> >> > will be no longer supported?
> >>
> >> release-notes recommends:
> >> https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#removing-non-debian-packages
> >
> >Which has nothing to do with what was asked.
> >
> >> Some people seem to recommend debfoster.
> >
> >Which really doesn't provide similar functionality.
> >
> >> > Leaving users in the void about this is just bad style.
> >
> >I totally agree. Not wanting to maintain it is a shitty reason for
> >asking for its removal. If you don't wanna maintain is, just orphan
> >it.
>
>
> It's really a maintainer call if that's appropriate.  So far no one has 
> jumped up to ask if they can take over the package.

Please. It's not like anyone was ever given the opportunity by
noticing a recently orphaned package or a blog post about it either.

Martin-Éric

Bug#1065312: RM: deborphan -- ROM; missing too many dpkg features, thus broken and unreliable

[Chris Hofstaedtler]

On Sat, Mar 02, 2024 at 03:16:22PM +0100, Chris Hofstaedtler wrote:
> Given the C codebase and lack of any patches so far I do not see that
> deborphan will ever get these features, and we have other tools
> available that work, do not mess with dpkg internals and are actually
> maintained.

As people have asked so nicely, and not at all demanding, entitled
or otherwise bossy in this bug report, I've checked around a bit how
APT provides deborphan's functionality today.

As you all know, apt keeps track of when a package was installed
manually or automatically. This is mostly equivalent to manually
maintaining a deborphan keep file, but automated. apt-mark can be
used to manipulate the manually-installed state.

On top of that, apt-patterns(7) documents how to select packages,
including on sections, installed status, manually-installed status.
It can also used to select based on package names and regexes.

Thus, a good approximation of the default deborphan functionality
(no additional options passed) is:

$ apt-mark auto '~i !~M (~slibs|~soldlibs|~slibdevel|~sintrospection|~sdebug)'
possibly followed by
$ apt autoremove

If you're using --guess- or --guess-section with
deborphan, you can copy the regex lists from deborphans source. A
lot of them are however outdated and wrong, so you were already in
"living dangerously" territory there.

And that's it. deborphan does not do any magic and you can do all of
it with apt.

Chris

Bug#1065312: RM: deborphan -- ROM; missing too many dpkg features, thus broken and unreliable

[Scott Kitterman]

On March 10, 2024 3:23:32 PM UTC, "Martin-Éric Racine" 
 wrote:
>On Sat, 2 Mar 2024 18:40:13 +0100 Chris Hofstaedtler  wrote:
>> * Christoph Biedl  [240302 17:02]:
>> > Chris Hofstaedtler wrote...
>> >
>> > > please remove deborphan. It is stuck, featurewise, in a very old time
>> > > and does not support many currently available dpkg features properly
>> > > (multi-arch, versioned provides, etc).
>> >
>> > FWIW, deborphan is part of my regular workflow, and while you claim
>> > it has defects, it works for me pretty well.
>>
>> It works "well" if you use it in very limited usecases, yes (like I
>> did). It doesn't seem to work well for a lot of people using more of
>> the "features" it has.
>
>Just because it doesn't work for everyone is not a remotely good
>enough reason to ask for its removal. It works for most people. don't
>break it for them.
>
>> The t64 transition will apparently make deborphan mostly useless in
>> trixie.
>>
>> > [..]
>> > So: What are the alternatives? How do they work? Are they a drop-in
>> > replacment or do they introduce new dependencies? Are there feature that
>> > will be no longer supported?
>>
>> release-notes recommends:
>> https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#removing-non-debian-packages
>
>Which has nothing to do with what was asked.
>
>> Some people seem to recommend debfoster.
>
>Which really doesn't provide similar functionality.
>
>> > Leaving users in the void about this is just bad style.
>
>I totally agree. Not wanting to maintain it is a shitty reason for
>asking for its removal. If you don't wanna maintain is, just orphan
>it.


It's really a maintainer call if that's appropriate.  So far no one has jumped 
up to ask if they can take over the package.

Scott K

Bug#1065312: RM: deborphan -- ROM; missing too many dpkg features, thus broken and unreliable

[Martin-Éric Racine]

On Sat, 2 Mar 2024 18:40:13 +0100 Chris Hofstaedtler  wrote:
> * Christoph Biedl  [240302 17:02]:
> > Chris Hofstaedtler wrote...
> >
> > > please remove deborphan. It is stuck, featurewise, in a very old time
> > > and does not support many currently available dpkg features properly
> > > (multi-arch, versioned provides, etc).
> >
> > FWIW, deborphan is part of my regular workflow, and while you claim
> > it has defects, it works for me pretty well.
>
> It works "well" if you use it in very limited usecases, yes (like I
> did). It doesn't seem to work well for a lot of people using more of
> the "features" it has.

Just because it doesn't work for everyone is not a remotely good
enough reason to ask for its removal. It works for most people. don't
break it for them.

> The t64 transition will apparently make deborphan mostly useless in
> trixie.
>
> > [..]
> > So: What are the alternatives? How do they work? Are they a drop-in
> > replacment or do they introduce new dependencies? Are there feature that
> > will be no longer supported?
>
> release-notes recommends:
> https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#removing-non-debian-packages

Which has nothing to do with what was asked.

> Some people seem to recommend debfoster.

Which really doesn't provide similar functionality.

> > Leaving users in the void about this is just bad style.

I totally agree. Not wanting to maintain it is a shitty reason for
asking for its removal. If you don't wanna maintain is, just orphan
it.

Martin-Éric

Bug#1065312: RM: deborphan -- ROM; missing too many dpkg features, thus broken and unreliable

[Scott Kitterman]

Generally in the FTP Team we trust maintainer's judgement when it comes to 
deciding if a package should be removed rather than orphaned and left to rot.

I looked and it's been about 5 years since anyone other than Chris has uploaded 
the package and he's the only human maintainer.

It is both a feature and a bug that in Debian, we're all volunteers and can 
choose how we volunteer.

I don't see anyone volunteering to step up and take over, so in the end, the 
maintainer's judgement is what has to control.

Scott K

Bug#1065312: RM: deborphan -- ROM; missing too many dpkg features, thus broken and unreliable

[Christoph Biedl]

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

Bug#1065312: RM: deborphan -- ROM; missing too many dpkg features, thus broken and unreliable

[Chris Hofstaedtler]

* Christoph Biedl  [240302 17:02]:
> Chris Hofstaedtler wrote...
> 
> > please remove deborphan. It is stuck, featurewise, in a very old time
> > and does not support many currently available dpkg features properly
> > (multi-arch, versioned provides, etc).
> 
> FWIW, deborphan is part of my regular workflow, and while you claim
> it has defects, it works for me pretty well.

It works "well" if you use it in very limited usecases, yes (like I
did). It doesn't seem to work well for a lot of people using more of
the "features" it has.

The t64 transition will apparently make deborphan mostly useless in
trixie.

> [..]
> So: What are the alternatives? How do they work? Are they a drop-in
> replacment or do they introduce new dependencies? Are there feature that
> will be no longer supported?

release-notes recommends:
https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#removing-non-debian-packages

Some people seem to recommend debfoster.

> Leaving users in the void about this is just bad style.

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".

Chris

Bug#1065312: RM: deborphan -- ROM; missing too many dpkg features, thus broken and unreliable

[Christoph Biedl]

Chris Hofstaedtler wrote...

> please remove deborphan. It is stuck, featurewise, in a very old time
> and does not support many currently available dpkg features properly
> (multi-arch, versioned provides, etc).

FWIW, deborphan is part of my regular workflow, and while you claim
it has defects, it works for me pretty well.

> Given the C codebase and lack of any patches so far I do not see that
> deborphan will ever get these features, and we have other tools
> available that work, do not mess with dpkg internals and are actually
> maintained.

One day I'm going to propose to make the following a policy about
removing a package: A phrase like "alternatives exist" without further
explanation should result in an immediate -done/wontfix for lack of
information. As this is in violation of the social contract #4.

So: What are the alternatives? How do they work? Are they a drop-in
replacment or do they introduce new dependencies? Are there feature that
will be no longer supported?

Leaving users in the void about this is just bad style.

Christoph


signature.asc
Description: PGP signature

Bug#1065312: RM: deborphan -- ROM; missing too many dpkg features, thus broken and unreliable

[Chris Hofstaedtler]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: deborp...@packages.debian.org
Control: affects -1 + src:deborphan

Dear ftpmasters,

please remove deborphan. It is stuck, featurewise, in a very old time
and does not support many currently available dpkg features properly
(multi-arch, versioned provides, etc).

Given the C codebase and lack of any patches so far I do not see that
deborphan will ever get these features, and we have other tools
available that work, do not mess with dpkg internals and are actually
maintained.

Thanks,
Chris