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.
Scott K
