Re: Roll existing backports into ELTS update for distro-info-data?
On Tue, Nov 01, 2022 at 10:21:45AM +, stefa...@debian.org wrote: > From buster onwards, we've been providing stable updates, rather than > backports. cool! > My issue here wasn't really about content, but about versioning and > changelog history. Either way, the package would have the same CSV files > inside it. for debian-security-support I've solved the versioning question by using different epochs per release. 11 for buster, 12 for bullseye, etc. > So, I based my LTS and ELTS uploads on the last accepted backports > uploads, to make upgrades seamless with or without the backport version > previously installed. cool! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ "There's no glory in prevention." (Christian Drosten) signature.asc Description: PGP signature
Re: Roll existing backports into ELTS update for distro-info-data?
Hi Holger (2022.10.31_23:43:42_+) > On Sun, Oct 30, 2022 at 02:08:18PM +, Stefano Rivera wrote: > > Back in those days, we used to publish distro-info-data updates via > > backports, not stable updates. So there were backports published to both > > stretch-backports and jessie-backports. Backports don't support LTS, > > never mind ELTS. > > there are no debian-backports for debian-lts, as debian-backports for a > release > gets closed once the release becomes LTS. Right, that was my issue. Historically the package was kept up to date via backports, because this was a lighter-weight process than stable updates. But obviously that couldn't continue into LTS, without the separate backports pocket. From buster onwards, we've been providing stable updates, rather than backports. My issue here wasn't really about content, but about versioning and changelog history. Either way, the package would have the same CSV files inside it. So, I based my LTS and ELTS uploads on the last accepted backports uploads, to make upgrades seamless with or without the backport version previously installed. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Roll existing backports into ELTS update for distro-info-data?
hi, first: thanks for maintaining d-i-d and for adding (E)LTS to it! On Sun, Oct 30, 2022 at 02:08:18PM +, Stefano Rivera wrote: > Back in those days, we used to publish distro-info-data updates via > backports, not stable updates. So there were backports published to both > stretch-backports and jessie-backports. Backports don't support LTS, > never mind ELTS. there are no debian-backports for debian-lts, as debian-backports for a release gets closed once the release becomes LTS. > Another option is to just ignore the whole thing, because chances are > that if nobody has complained yet about old data, maybe they never will :) heh, true. that said: using d-i-d is also rather new (in Debian timeframes) and so is (E)LTS... -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The law, in its majestic equality, forbids the rich as well as the poor to sleep under bridges, to beg in the streets, and to steal bread. (Anatole France) signature.asc Description: PGP signature
Re: Roll existing backports into ELTS update for distro-info-data?
Hi Stefano, I would say we should rely only on release and security suites, Backports are optional. Just be sure to provide a smooth upgrade from both release and backport suites. Regards Anton Am So., 30. Okt. 2022 um 15:08 Uhr schrieb Stefano Rivera < stefa...@debian.org>: > I'm an uploader for distro-info-data (a data only package like tzdata, > mostly useful to distro developers, but also potentially sysadmin > tools). We try to get updates out to all supported releases, but I > haven't been updating it in (E)LTS, before I joined Freexian & LTS. > > I just did a round of updates now, including LTS, because I can, > trivially. > > I see it in ELTS customer's package lists, but we have never issued an > update in ELTS. I can do updates for jessie and stretch ELTS, easily > enough (and fairly quickly), but quickly hit a policy question: > > Back in those days, we used to publish distro-info-data updates via > backports, not stable updates. So there were backports published to both > stretch-backports and jessie-backports. Backports don't support LTS, > never mind ELTS. > > So should I start (and version) ELTS updates based on the release suite > or the backport suite? I have to use the latter to ensure that users who > installed the backport get the update. > > Where do we usually stand on existing backports, when issuing updates? > > Another option is to just ignore the whole thing, because chances are > that if nobody has complained yet about old data, maybe they never will :) > > SR > > -- > Stefano Rivera > http://tumbleweed.org.za/ > +1 415 683 3272 > >
