Re: Request for Removal: Unmaintained libppd in Debian
On 30/12/2022 06:19, Christoph Biedl wrote:
Christoph Biedl wrote...
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.
Status update:
The renamed src:libppd package was just uploaded as src:libppd-legacy.
Great, thank you.
[...]
@Till: There are some things you could start working on:
First, you could upload your libppd as soon as -legacy was ACCEPTED.
As I understand things, there's no need to RM the old one, although it
could make things more obvious to observers.
I will prepare the package right now ... The actual upload needs to get
sponsored, as I am not a Debian Developer. Thorsten could most probably
do this. Once in Debian, we will sync into Ubuntu.
Also, as I prefer to be open in what I do, and especially here where
we're doing something rather unsual: Let's give some clues to those
who are disturbed once they ever discover this process. In other
words, I'd appreciate if you could add a transition notice in the
descriptions of your packages, until trixie, something like "Debian
used to ship a different software as libppd0, that one is now provided
via libppd-legacy-dev and libppd-legacy1".
I will add appropriate info to the package. So I should use the package
descriptions (in debian/control) for that?
If you want to upload *all* your new stuff to Debian - and I haven't
understood yet what is preventing you from doing so:
What prevented me from doing so was Thorsten telling me that it is to
short before Bookworm. So I suggested this Ubuntu-only roadmap in an
earlier e-mail in this thread.
We can naturally also:
1. Upload it into Debian right away and let it be the cups-filters of
Bookworm.
For this note at first that we are not required to switch into the New
Architecture by that. Including all the 5 parts we have the same
functionality as before, especially classic CUPS filters and PPD file
support for CUPS 2.x. Especially for now I have developed using libcups2
and not libcups3. From libcups2 nothing PPD-supporting is used so that a
later transition to libcups3 will be easy.
All the code stems either from the former cups-filters, libcups, and the
ppdc/ subdirectory of the CUPS (2.x) source (PPD compiler). So the risk
of a severe design flaw is low. There can be bugs still, but we are not
yet releasing Bookworm but still going through a testing and debugging
process. I also expect to do final (2.0.0) releases of the components
within 1-2 months.
So replacing cups-filters 1.x by all the the components of cups-filters
2.x should be smooth.
We sync then to Ubuntu.
2. Upload the new packages to experimental and sync to Ubuntu from
experimental. This way we skip Bookworm and promote to unstable when
unstable opens for the next Debian development cycle.
I would also send
a message like "News from the CUPS printing in Debian" to debian-devel
where you, among all the other things, would mention the libppd
situation, and how we resolved it. This would also be of help in my
upcoming discussiong with the release team: My change to libppd
implies a transition, even if it's about just one package (gpr).
No problem to send such a message.
So finally about the time frame: Transition freeze will be in less
than two weeks, so there is not much time to lose. Unless they are
willing to grant an exception for that minimal situation, but I'd
prefer to not exercise that.
I think I will be able to do the Debian packaging of the 5 components by
then.
Till
Reply to: