On Sat, 3 Aug 2024 at 11:20, Paul Gevers <elb...@debian.org> 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.
Thank you. For this particular case: there would be 2 uploads for every cycle, one at the end to add version numbers (this already happens, no?), one at the beginning to change the VERSION_CODENAME. I think from the point of view of requiring manual labour it should be pretty lightweight compared to the current workload of managing stable-p-u, at 2 uploads to review once every ~2 years, right? For the binNMU side, this would be an Architecture: all package, so it doesn't apply I think, right? It wouldn't be subject to any binary transition for library bumps or things like that. In the current proposal I am putting forward it's a binary arch: all with a single fixed arch-independent text file in /usr/lib/ and a single fixed symlink in /etc/ to the file in /usr/lib, no maintainer scripts whatsoever, no dependencies.
