Hi there,
Till Kamppeter wrote...
> Christoph, as you are the Debian maintainer of it, I want to ask you whether
> this package has still any use or whether you could invoke the process of
> requesting removal of it.
First, to avoid any misunderstanding: My motivation to take
maintainership of libppd (I'll use the name "legacy libppd" from now on
for clarity) in Debian was that package being in dire need of attention,
again. Following Debian's social contract, my interest was users of that
package are not harmed by its removal from the next release. Besides
that, I have no particular connection to it, in other words: Once I'm
convinced that package's time has passed and we can safely remove it,
I'll not hesitate to start that process.
However, I have concerns.
About users, you wrote:
> So I am very confident that there is nobody using this package and if it
> goes away, nobody will complain. If there is actually some other package
> using this, it is probably also unmaintained for at least a decade and
> nobody uses it.
Or it's feature complete and the users are happy :)
Unfortunately, I cannot agree here. According to popcon¹, we still have
users in the low three-digit range. It it was *two*-digit, I'd just say
"Let's ditch it". The given situation however requires more checking. In
my assumption the users are usually those who installed gpr ("GUI for
lpr: print files and configure printer-specific options") which depends
on legacy libppd.
Now gpr itself is in a bad state, and appearently the maintainer did not
react to a release-critical bug in months - a bug probably caused by
yours truly but still.
So in order to remove legacy libppd, we'd have to remove gpr as well,
and for both it was kind to give users an idea what to use instead -
personally, I get very upset if a package removal just says "Lots of
alternatives exist" without giving any clue how they are named and how
to migrate. (And often they are similar, nothing else.)
And there is another issue: Even if we remove both source packages from
the archives and you upload yours, some users will still expect the
legacy libppd-dev, and experience breakage. Now I don't know if there's
a grace period before re-using a source or binary package name, but I'd
say it's prudent to wait at least one Debian release cycle.
Don't get me wrong: I don't want to block your plans - I just want to
make sure the migration causes as little damage as possible.
To recap: There are two conflicting package names: The libppd source
package, and libppd-dev created from that.
So, solutions I can think of:
1. Remove legacy libppd and gpr (following your request)
Work need boils down to create guidelines for the users, which is
some work to do. If going that way, I could use some hands-on here.
2. Allow co-existence by renaming legacy libppd
The conflicting binary package from (legacy) libppd is renamed to
avoid a conflict with your version. So "libppd-dev" could become
"libppd-legacy-dev", and keep policy 10.1 in mind². Also, gpr needs
an according adjustment. I would take care of that as well.
The source package name is a different story. In your position I'd
rather prefix all these so it becomes obivous they belong together,
so perhaps "openprinting-libppd". As an alternative, I could rename
the source package as well, at the increased risk of confusing a few
users.
As a safeguard, you could consider adding some conflicts against the
legacy packages until the 13 ("trixie") release so those are not
installed by accident. Also, your libppd-dev should see an epoch to
make sure its version is above mine (currently 2:0.10-8).
Biggest concert for me: An updated legacy src:libppd would have to go
through NEW, nodoby knows how long that will take.
3. Allow co-existence by naming your package differently
We can avoid all the hazzle if ship your packages with a
non-conflicting name (like "openprinting-libppd-dev"). And we'd also
avoid user want my package but get yours.
That's no work for me :) But it feels bad since it does a change in
the new place - a place that will stay longer than the old one.
My preference is 2-1-3, and I'm open for other suggestions.
Aside, I guess you want to have that resolved in bookworm already? Then
let's not waste time, freeze is getting close.
Regards,
Christoph
¹ https://qa.debian.org/popcon.php?package=libppd
² Assuming you already have a packaging, mind to share the file list of
that one?
Attachment:
signature.asc
Description: PGP signature