On Fri, 2020-10-23 at 08:05 +0200, Axel Beckert wrote: > Ack. Just have to think how I make that separation properly. Either by > listing all supported previous release names (or maybe just those not > yet archived) and defaulting to the new scheme to be comaptible with > all future releases.
That sounds OK to me. Dropping the unsupported releases seems appropriate, unless xen-tools also supports using archive.debian.org for those releases, in that case you should keep all old releases. > I'd rather avoid this seemingly debian-specific dependency (c.f. > https://salsa.debian.org/debian/distro-info/-/blob/master/debian/copyright > and the native package version number) as xen-tools should also be > usable on other distributions. distro-info is in a few distros, similar ones to xen-tools: https://repology.org/project/distro-info/versions https://repology.org/project/xen-tools/versions > I disagree since distro-info is debian-only and that's a clear no-go. > Also these numbers won't change in the future once they're released, > so hardcoding won't do any harm. The issue with hardcoding is the maintenance cost of having to remember to add the new versions for every release. > > It might even be a good idea to include the security > > suite information in distro-info itself and look it up there. FTR I filed #972750 about this idea. > I'd rather add it to xen-tools' etc/distribution.conf which basically > tracks the needed setting changes per release: > https://github.com/xen-tools/xen-tools/blob/master/etc/distributions.conf I think it is better to have these sort of things in one central place rather copies in every script that needs the information. -- bye, pabs https://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
