On Sat, 3 Aug 2024 at 12:39, Sebastian Ramacher <sramac...@debian.org> wrote: > > On 2024-08-03 12:20:09 +0200, Paul Gevers wrote: > > Hi > > > > On 03-08-2024 11:58, Luca Boccassi wrote: > > > > On the use of tpu: > > > > Personally, until now I fail to see enough value of being able to > > > > distinguish unstable and testing to give the package carrying > > > > /etc/os-release a permanent exception via tpu. > > > > > > Thanks for chiming in - assuming for a moment that it is decided that > > > the change will be implemented, do you see any technical obstacles in > > > using t-p-u as proposed? > > > > The biggest reason I know against using tpu is that it currently isn't > > receiving the same amount of testing (be it automatic (autopkgtest, > > piuparts, in the future reproducibility) or human) as unstable-to-testing > > migrations receive. For the automatic part, that's obviously a solvable > > problem (and already on my todo list for YEARS), but currently not the case. > > It also *always* requires human intervention by the Release Team. Another > > issue issue with tpu is that binNMU'ing is more difficult (I assume that's > > probably not very often relevant in the current case). I recall there are > > more issues with tpu, but I have forgotten them. When I find them, I'll add > > them. > > To add to that: tpu is used for exceptional cases only. Cases where we > deem the result of the upload more important than the additional > work required of a release team member. Cases where we deem RC bugs > potentially introduced by missing QA for tpu uploads less severe than > the issue we are trying to fix in testing. Essentially, if it is not a > critical bug (think xz incident critical), going through tpu during non-freeze > time never happens. > > For a package that is part of the essential set, having all the QA tools > checking the consequences of the inclusion of this a package is really > essential. Skipping out on QA checks for an essential packages that > would normally run for typical unstable to testing migration puts even > more pressure on the release team to make sure that accepting the > package from tpu does not severly break testing. > > (As side note: in essentially all cases where I handled tpu uploads > (that I remember) during non-freeze time, it was more effort to untangle > unstable so I have asked maintainers explicitly to perform tpu uploads.)
In the generic case, sure, I see all of that making perfect sense. This though is about one very specific and narrow case: an arch: all package with a single, fixed and inert text file, that differs by one line. No maintainer scripts that run on install/upgrades and could fail, no programs that run on install, no dependencies that might not be available or installable, one reverse dependency for one cycle to ensure installation in existing images and then it will be removed. And it's one upload at the beginning of a cycle, and then it stays as-is for 2 years until the next, so there is no continued effort nor need to watch it. At each cycle there is a lot of work to do to prepare the next testing pocket I imagine - creating new aliases and whatnot, so in the context of that and compared to the size of that work, this appears to me as a minor addition, no? Which is not to say it's nil or doesn't require any effort ofc. The QA effort I see is: diffoscope old.deb new.deb and verify the difference is only in the changelog entry and the VERSION_CODENAME= field. For this specific and precise use case, do you see the requirement for any other QA effort on top of this, and if so could you please clarify what it would entail? > Also, we have been pushing to keep testing and unstable as close as > possible. Packages not migrating for some time are considered RC buggy > to reduce the difference and where Paaul is thankfully filing the > corresponding bugs. Going through tpu would essentially introduce a > package that is auto-RC buggy in the essential set with consequences: it > causes even more divergence for autopkgtests in testing (reference > tests), in testing + pinned packages from unstable for migration checks > and in unstable. That would cause potentially even more work (for the RT > and maintainers) to figure out why some test is failing in one > configuration and not the other. I deal with fairly complex autopkgtest in debci all the time, for systemd and related packages. The differences between testing and unstable at any given time are so massive due to things like the kernel having a fast development and upload cycle with lots of point releases, a one line difference in one text file seems extremely minor compared to the mountain of other things that are ongoing at any given time. For example, right now literally everything is broken and has been for months due to a kernel bug that makes it impossible to do autopkgtest with a qemu guest. Do you have any specific indication for this exact use case of t-p-u, rather than the generic issues with t-p-u, that you could see apply here? > But keeping all of that aside, I don't see any label that could be > included as a static file in a package that would be correct due to the > duality of testing. trixie is defined by what we release on release day. > Labelling it trixie before that would be wrong as there are cases where > creating a "trixie" image before release will not end up with a trixie > image as produced after the release (just install something that is > later removed from testing). It would be labelled incorrectly as trixie > if users created it with testing or as testing + unstable. Any users may > add experimental to the mix as testing + sid + experimental which would > also be mislabelled. Testing is already labeled 'trixie' as we speak, you can verify that by cat usr/lib/os-release of your nearest testing os tree. And it depends on what you mean by "correct" - again this is about the os-release specification, and I can assert that it is 100% correct that right now 'debootstrap trixie foo' and 'grep VERSION_CODE_NAME foo/usr/lib/os-release' returns 'trixie'. You might say from other points of views/workflows/etc that's incorrect - but not from os-release. Other content doesn't matter, it's irrelevant that something will change on release day or after, os-release's VERSION_CODENAME does not apply only to stable releases, and there are other fields to express "this is in development and might change a lot", and it's not VERSION_CODENAME. Content changes in stable too after release day all the time. Debian Bookworm shipped last year with a kernel and a systemd that are radically different from what is available today in Boowork 12.6, with many different bug fixes and bugs that alter its behaviour in dramatic ways in certain conditions. It's still Bookworm though. Because the os-release specification doesn't say that you have to pin point an exact set of content at any give time and identify that via VERSION_CODENAME. There _is_ an appropriate way in os-release to identify the whole content at any point in time, and that's BUILD_ID, and we do not use it. There is an appropriate way to label a tree as "work in progress" or "lots will change", and it's the newly added RELEASE_TYPE=development. Given this is expressly and solely about os-release, if you or anybody else haven't done so already, I would highly recommend to spend a few minutes to scan through https://www.freedesktop.org/software/systemd/man/devel/os-release.html and see what all the fields are about. The "devel" part in the url makes it point to the unreleased version as it is in git main (but note it's not updated automatically as of now, working on it). > Without checking the apt configuration (including the > Default-Release setting) and its sources configuration, there are always > cases where the label is incorrect during our typical release process > (and even then priorities may make it impossible to label properly). > Labelling testing as $selected_release_name/sid is a good enough > and more importantly an established compromise to label what will > become the next release up to the freeze. I understand it is good enough for certain use cases or some other people, but for myself I can say it is most definitely and dramatically not good enough as a user, as a manager of images, and as a developer of image building tools, and it's in fact, really, really bad, as it confuses and mixes two radically different types of images, forcing me to reach for Debian-specific kludges that are unnecessary everywhere else, making Debian stand out as a bad base to work with, and as a buggy implementation of the specification. One is a development release that will have a version + 1 and doesn't have version - 1, will one day become stable and gain security support, and then become ELTS and lose some security support, and then become EOL and lose any support and any updates and require moving to a different release. That's trixie. The other is a rolling release that doesn't have a version -1 and will never have a version+1, will never have security support, will never move to a different team maintenance, will never become EOL and require moving to a different release. That's sid. >From this point of view, they are radically different and need to be treated differently, and if I have laying around a sid image and a trixie image, I need to treat them very differently, as one has a finite lifespan and the other does not. This is what os-release is about. I understand there are different workflows and concepts where different conclusions apply, but from the narrow context of os-release, testing is technically correct right now, and unstable is technically incorrect. One might say it's fine that this is the case, and it is better to leave it as such of course. If anybody asks me, "is Debian a good base for an image-based Linux OS?" my answer is "no, stay away, don't even touch with a barge pole", and I find that incredibly sad, and that's why I've been working for a long time to make that better. This is just one more (small) part of it - not the only one, not the biggest, not the most prominent, but still part of the reason for that sad and disappointing answer.
