Hi Robie! Firstly, thank you for driving this! This is also something that has been on my mind this cycle.
Responses inline. On 4/2/25 08:55 AM, Robie Basak wrote:
Some packages that are Ubuntu-only have `ubuntu` in the version string, which automatically stops autosync, which is probably what we want. Other such Ubuntu-only packages do not, so if Debian were to package something with the same source package name, it may autosync, which is probably not what we want. Unless it's in the sync blocklist, but now there are three possible states for an Ubuntu-only package to be with respect to autosync, which is just unnecessary work for concerned reviewers. I just reviewed the following SRUs, which (sort of) uses a mix of both: lxd-installer | 1 | focal | source lxd-installer | 1 | jammy | source lxd-installer | 4 | noble | source lxd-installer | 4ubuntu0.1 | noble-updates | source lxd-installer | 4ubuntu0.2 | noble/unapproved/39f530b | source lxd-installer | 8 | oracular | source lxd-installer | 8.1 | oracular/unapproved/74f18e3 | source lxd-installer | 12 | plucky | source Could we agree that all Ubuntu-only packages SHOULD always contain `ubuntu` in their version string (this would usually be -0ubuntuX or 0ubuntuX[1] if native) then, so that we don't have to think about it?
As explicitly defined under RFC-2119, I am in agreement that "SHOULD" is precisely correct.
Are there any reasons for an exception to this rule, where an autosync would actually be desirable if Debian were to introduce such a package? If it's not for a common reason, then perhaps an additional policy might be that there SHOULD be something in debian/README.source that explains any deviation from this.
I can think of one specific case where an exception to the rule would be warranted, and it is somewhat rare. Sometimes, we need to introduce a brand-new source package late in a cycle, for a good reason. Take the extreme case where the Debian NEW queue is like, 1000 packages. Rust, or something. That package is uploaded to both Ubuntu and Debian at the same time. The uploader states their good reason, an AA does a full review, it gets accepted with a lower version number (0ubuntu1). The package is then accepted into Debian at some later point, with the exact same (de-facto) maintainer. For the sake of argument, the uploader is both a Debian Developer and an Ubuntu Core Developer. It would make sense to drive that through in Debian most of the time. Where I believe an exception would be warranted is, a "halfway" point between "buildX" and "ubuntuX." I typically use this when I need to make substantive changes to a package that already has those changes in Debian, e.g. past Debian Import Freeze. I don't want to have it waiting on someone to sync it the following cycle if I forget or don't look at MoM, and it's not a no-change rebuild so "build1" simply isn't accurate. In this case, I've been using "syncable" instead. I have also noticed "maysync" as another one. We can't forget about "fakesync". Version Numbers Are Cheap. It's somewhat frustrating that `dch` wants to append "ubuntu1" on the end of these suffixes anyway, but that's a half-second trivial fix. To make a long story short, I'd probably attempt to use the "syncable1" suffix if I did that in 2025, at the very least to try to get some discussion going about what the Archive Admins would prefer at scale, given there is a safe stop-gap.
[1] No need for an epoch to comply though I don't think.
Yeah, no epochs as part of this, please. Best regards, -- Simon Quigley si...@tsimonq2.net @tsimonq2:ubuntu.com on Matrix tsimonq2 on LiberaChat and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
