Hi Paul, Paul Wise wrote: > 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,
That's not what I meant! I meant that I probably not have to list releases no more supported by Debian as the "eol" flag in etc/distributions.conf already implies that I don't have to care about security updates anymore. > unless xen-tools also supports using archive.debian.org for those > releases, Of course it does! Back to Sarge and Dapper you can install any Debian and Ubuntu release in a Xen DomU. That's really helpful if you want to do software archaeology on living subjects and not just in a chroot, like checking if some kernel coped with some other thing or so. > > 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: Thanks for checking. I though wonder why it has a native package version number in Debian then. Will think about it, but it's not likely that I'll do that soon. xen-tools is more or less in maintenance mode as I only use it seldomly myself anymore after changing jobs. (I used it a lot on my previous job which is one of the reasons why I adopted it about 10 years ago.) > > 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. I have to do that anyway, so I currently see no point in adding that dependency, unless I a) revamp the whole tool, e.g. automating the list of distro symlinks in Makefile (or rewriting the whole toolset so that it fetches the information live while running on the Xen host system), but both still needs to know which distribution release are the same in terms of set of scripts: https://github.com/xen-tools/xen-tools/blob/master/Makefile#L178-L231 And b) all the information currently in etc/distributions.conf would have to be in distro-info — including which distributions are testable and which distributions are equivalent with regards to the set of scripts. (See above.) I doubt that this will actually work out. I may then have to maintain it in less places, but I'll still have to maintain this data set _and_ check that my dependency has that data, too. > > > 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. Thanks, subscribed to it. > > 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. While I generally agree, I'm not sure if you are aware that there's some quite xen-tools specific facts in there like e.g. which distributions are supported at all and which distributions shouldn't be run in the test suite. I'd rather have all those information in one place than split over my repo and some other tools. That information about which GPG keyring to use is probably not in distro-info either. Anyway, looking at /usr/share/distro-info/*.csv there's indeed some quite useful data in there, like the EoL dates. I think I might have some use for that in another project of mine. But then again, ubuntu.csv misses the ESM dates and debian.csv misses the LTS/ELTS dates despite the latter is an open bug report since 2015 (https://bugs.debian.org/782685 — Hey, this bug report was even filed by myself! *sigh*) and marked as pending for more than a year despite there were two uploads of each, distro-info and distro-info-data since then. So I think I can say that I'm not too happy with the amount of information being in there and also have some doubt that more columns are actually added anytime soon. Regards, Axel -- ,''`. | Axel Beckert <a...@debian.org>, https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
