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. 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. (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); (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. 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 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. > So the identification will be as it is right now, it will depend on the > version of the package providing the os-release file, which like any > other package can be manually overridden, upgraded, downgraded if one > really wishes to do so. Thanks, that answers the question that I was asking. You're keeping the same semantics as we currently have with base-files, and you're proposing maintaining two different lines of development for the package containing this file, one for unstable and one for testing. > There are for sure a lot of criticisms of the bugs in base-files, but > there are no insults. Debian would be a far more enjoyable project to work on if you would recalibrate your understanding of what is an insult. Right now, it requires substantial effort to read any thread that you have replied to because I have to brace myself for judgmental, emotionally loaded, and hostile-sounding language that gets in the way of understanding the root disagreement and having a cordial and constructive collaboration. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
