On Wed, 04 Oct 2023, Santiago Ruano Rincón wrote:
> > We could have a single file per release with 3 fields:
> >
> > * package (or package regexp)
> > * supported (true/false), trues implies limited support, false means not
> > supported
> > * comment (should explain the limitation if supported == true)
[...]
> I like the above suggestion. Just wondering why don't keep the "latest
> version with support" and "Date when support ended or will end" fields
> currently found in "ended" files.
It's just an oversight, I forgot about those fields.
But to be honest, I'm not sure that the first one is actually useful: what
does "latest version with support" mean? Version X might be supported now
and might no longer be supported in one year. And how does it mesh with
backports?
The date one might be more useful indeed, when we decide to follow the
upstream support schedule for instance.
On the opposite, it might be useful to be able to say that the source
package is still supported but only when you use at least version X
because we have switched to a backport of a new upstream version compared
to the version initially provided (it would be a special case of limited
support? or maybe we need to have different types of entries in the file?)
(If we make those changes, it's probably also the right time to take care of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765452 with the
possibility to exclude some binary packages.)
Cheers,
--
⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
signature.asc
Description: PGP signature
