On Thu, 17 Oct 2024, John Scott wrote:
I have a question as a random passerby.
Thorsten Alteholz wrote:
libcupsfilters2-common is part of the new CUPSv3 family of packages, but this
is far from being ready to use.
Nowadays nobody should use libcupsfilters2 at all.
If libcupsfilters2 is not ready for end user systems and is only to play with
right now, wouldn't it be better to keep it in experimental?
CUPSv3 is a whole family of packages and their interaction needs to be
tested. At the moment nothing useful besides installation can be done. Of
course this will change and depending on upstreams development, there
might be even a preliminary version ready when Trixie will be released.
For sure it won't be a final version, but at least it might be used and
tested in different environments. Experimental should be used to prepare
library transistions, but almost nobody really uses package from
experimental to test anything. So no, it would not be better to upload
libcupsfilters2 to experimental.
Having it migrate to testing and hence be slated for the next stable
release sends the message that applications can use it and it will be
supported for the release lifecycle.
Sure as libcupsfilters2 works as intended, applications can use it. But
they need to use it as intended in the Debian way and not in the Ubunutu
way.
Ubuntu plans to switch from CUPSv2 to CUPSv3 at an arbitrary date. After
that date printing on the unstable/testing equivalent of Ubuntu is broken.
Nobody knows how long it will be broken as it is not possible to test
CUPSv3 before that switch.
In Debian CUPSv2 and CUPSv3 exist in parallel. They can not be installed
at the same time, but one can at least switch between them, test whether
every printer is still working and find bugs. So it is important that
all package are available. When CUPSv3 can really be used to print a page,
depends on upstreams progress.
It's not very helpful to have this
package in the next stable release if people aren't actually supposed to
use it.
The next release is in about half a year. How do you know today what will
be the correct way then?
If that isn't possible, a crude hack that gcc-snapshot and like
packages use is to keep a high-severity bug report intentionally open to
prevent migration to testing.
Sure, this can be done, but it is way to early to decide now what is best
for the Trixie release.
Thorsten
