Hello, On Sat 19 Oct 2024 at 08:49pm +02, Guillem Jover wrote:
> I understand that manual part being a bother, although I'd assume > there is tooling to automate most of the work from a properly > formatted overrides change bug report? There is not, unfortunately. > In any case, I think having this information available in an easily > accessible and machine readable way, even if it's for a short period of > time (say from release to release), is rather helpful for local > infrastructure tooling, site admins, etc. So perhaps a better solution > might be to completely move away from the oldlibs section (which is a > misnomer anyway in many cases :) which requires both changes in the > packaging and then confirmation by the archive admins, and instead > leave the sections as they are, and then add new fields to denote their > obsolescence/deprecation/superseding > > Things that come to mind could be for example: > > Package: oldthing > Section: admin > Obsolete: yes > Depends: newthing-a | newthing-b, newthing-plugin > Description: empty transitional package obsoleted by something else > > Package: liboldthing-dev > Section: libdevel > Superseded-by: libnewthing-dev > Depends: liboldthing1 > Description: library doing something (deprecated) > This is a deprecated library that should no longer be used by new > packages, it has been superseded by libnewthing, please switch to > use that. > > (I've now written a brain-dump for the above at > https://wiki.debian.org/Teams/Dpkg/Spec/DeclarativeObsoletePackages, > will be rummaging over it for a bit and then at some point propose > that on d-dpkg and d-d.) Hmm interesting. It is certainly true that oldlibs is a misnomer. Thanks for looking into it. -- Sean Whitton
signature.asc
Description: PGP signature
