On Sun, 10 Mar 2024 15:27:21 +0000 Scott Kitterman <deb...@kitterman.com> wrote:

On March 10, 2024 3:23:32 PM UTC, "Martin-Éric Racine" 
<martin-eric.rac...@iki.fi> wrote:
>On Sat, 2 Mar 2024 18:40:13 +0100 Chris Hofstaedtler <z...@debian.org> wrote:
>> * Christoph Biedl <debian.a...@manchmal.in-ulm.de> [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.

Attachment: OpenPGP_0x645D0247C36E7637.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

Reply via email to