On Thu, 1 Aug 2024 at 20:06, Russ Allbery <r...@debian.org> wrote: > > Luca Boccassi <bl...@debian.org> writes: > > > I was about to say that the proposal is in the linked bug, but it has > > disappeared - it could be due to the bugs getting unlinked. Anyway, my > > variant is here: > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675731#54 > > Ah, thank you. I think that answers my questions. > > To summarize briefly to ensure that I understand, your proposal is to > separate only this content into a second package, make base-files depend > on it, and then maintain different versions of that package in unstable > and testing. > > There are two technical aspects of this proposal that worry me. > > The first is adding a dependency to base-files. I know people have put a > whole lot of work into pure dependency-based bootstrapping for Debian, but > historically base-files has been very special and posed lots of > interesting complications that are separately handled in lots of different > tools.
It could be a dependency of something else, or it could be marked as essential itself, given the content is a 5 lines text file and a symlink it shouldn't be too hard to figure out an acceptable way to ensure it ships everywhere. It doesn't have to be related to base-files at all, it was just the first thing that came to mind. > I do agree with Santiago's desire to maintain base-files as a "normal" > Debian package that gets tested in unstable and propagates to testing, so > if we go down this route, splitting out this data does seem better to me > than maintaining multiple lines of development for base-files itself. > > The second thing that I'm not fond of is giving testing the version number > 13 when we plan on using 13 as the version number for the trixie release. > I fear that if we do that, someone (probably a third-party package > provider) will add some workaround or behavior change for a package based > on that version number for a problem that only ever existed in testing and > that was not in the actual 13 release. I would instead expect testing to > use some version number that is between stable and the version number that > will be assigned to the next release, to reflect that it is likely to > change substantially before Debian makes an actual release 13. The version number is the least important part of the changes - so for example, it could still be omitted until the actual release like it is now. The really important part is adding different and separate codenames, so that a testing image can be reliably and univocally distinguished from a sid image, and VERSION_CODENAME is enough for that, the version number is cherry on top. I still think that trixie is 13 and 13 is trixie, so there's no point in delaying, as that piece of metadata is not going to change, and I think it would be better if "debootstrap trixie" always gave the same identification metadata (barring the release type as per below perhaps) but it's not a crucial matter and it's fine either way, in the end. But this example seems a bit too tortured to me. First, if you add a workaround like that, you would normally do it based on the package version you are working around, or at least that's how I usually do it and see it done. And secondly, that same strawman can be applied to stable, as we do point releases and security uploads. One could see a bug in bookworm and decide to check for VERSION_ID=12 to work around it, even if that bug is later solved in a point release or security update. It is still correct to mark stable as VERSION=12 (without the point release). > (If I were designing this from scratch, I'd give serious thought to using > even version numbers for releases and odd version numbers for testing, > similar to how Perl releases are versioned for very similar reasons. But > that's probably too big of a change for the level of benefit.) > > Presumably the RELEASE_TYPE setting of pre-release is supposed to help > with that, but (a) that variable doesn't seem to be documented in > os-release(5); What do you mean?!! It's right there! https://www.freedesktop.org/software/systemd/man/devel/os-release.html#RELEASE_TYPE= ...ok, ok, it's there now because I just merged it and regenerated the docs :-P > (b) the sorts of packagers that I'm worried about are quite > likely to not make subtle distinctions like that, so the version is still > there as a potential foot-gun for people who aren't paying close > attention; and (c) I would argue that calling testing a "pre-release" is > not very accurate, since that applies that the contents are very similar > to the eventual release and are in a relatively late stage of testing. As above, if someone wants to abuse the version to pin things, it can already happen in all stable point releases too. In fact with kernel upstream LTS releases being part of those, the amount of changes in a Debian stable point release is actually quite large, and it does happen often that those kernel LTS releases either break egregiously or fix egregious breakages. > There's a lot of merit to Santiago's decision to not give unstable a > version number that I think still applies to testing even when it's > considered separately. However, you do have a good point that this makes > life difficult for third-party packages that want to enforce a minimum > version number because there's no way to then tell that, although this is > a testing release with no real version number, it does come after version > 12. (Obviously this is not a great way to handle dependencies on a Debian > release, and we probably wouldn't allow it in a regular Debian package, > but third-party packages often do things like this.) I'm not sure which > side of that trade-off I'd fall on, although I do think not having a > version number is more semantically correct given the current language > documented in os-release(5). If RELEASE_TYPE were added to the spec with > an additional type of "development-snapshot" or something else more > accurate than "pre-release", that might change my mind, although my point > (b) above still applies. There ya go: https://github.com/systemd/systemd/pull/33904 I omitted 'snapshot' as that sort of implies a fixed content, which for package-based distro seems inaccurate. > > There was also a slight variant by Gioele, that again I fail to find now > > and it might be because of the bugs being rearranged, where > > testing-proposed-updates is used to upload testing-specific content. > > That seems like a better approach than the one proposed in the message > above, although I think it requires some manual intervention by the > release team. This doesn't seem like a serious problem given that uploads > are presumably quite infrequent and the package is trivial. Yes if that does end up happening, it would probably require flagging it to stop autoremoval via a hint or something like that, but it naively feels like an eminently solvable problem, and very much secondary to the core issue, which is, "should the os-release spec be adhered to and unstable vs testing made identifiable"
