[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: