> On Mon, May 19, 2025 at 05:10:44PM +0000, Benjamin Drung wrote:
>> I am a little late to the party.
>
> Way later here :)
I just discussed this with some people at DebConf in the context of rust-hwlib,
which is another Ubuntu-native package. I guess the general suggestion is to
avoid Ubuntu-native packages in the first place, thus avoiding this whole
situation, as we can just use a common VERSION-0ubuntuX version string.
>> On Tue, 2025-04-08 at 11:49 +0200, Christian Ehrhardt wrote:
>>> On Tue, Apr 8, 2025 at 9:29 AM Julian Andres Klode
>>> <julian.klode at canonical.com> wrote:
>>> >
>>> > On Wed, Apr 02, 2025 at 02:55:46PM +0100, 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?
>>> > >
>>> > > 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.
>>> >
>>> > Funny enough I had that same conversation with Scott James Remnant many
>>> > years ago on upstart, which had like 0.1.0-1 versions in Ubuntu at the
>>> > time.
>>> >
>>> > I also had exactly the problem where it synced software-properties
>>> > from Debian because it was not in the blocklist, and software-properties
>>> > Debian packaging ended up weird (0.90debian1, possibly not an actual
>>> > version number)
>>> >
>>> > But also this is going to get even weirder if we have a package we
>>> > develop and start to use the ubuntu version string. Then my Debian
>>> > version of foo 1ubuntu1 will end up 1ubuntu1debian1.
>>> >
>>> > Like I can guarantee you, someone will upload 1ubuntu2 with code
>>> > changes and the Debian uploader will need to package that, rather
>>> > than a 2ubuntu1.
>>>
>>> True and backed with a real story,
>>> but I feel we should still strive to make the normal cases better and
>>> consistent,
>>> despite the existence of edge cases - WDYT?
>>
>> I read the full discussion and the current
>> https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/VersionStrings.md
>>
>> I dislike adding `ubuntu0` to Ubuntu native packages because it is
>> confusing. I have different alternatives to propose.
>
> +1.
> I was just reviewing this ubuntu-advantage-tools (pro client) merge
> proposal and I realized a new `ubuntu0` suffix was added to the package
> version after this discussion.
>
> I understand this was done for the sake of complying with the proposal
> in this thread, and more specifically, to Benjamin's reply. However, the
> `0` after `ubuntu` seems to serve no purpose there. if we are releasing
> version `36ubuntu0` and need to add a missing `Depends` to this native
> package, we will bump the version to something like `36.1ubuntu0` and
> never to `36ubuntu1`.
>
> This new format seems to hinder automation for tools like `dch` to
> automatically bump versions in changelogs.
I agree the "0" after "ubuntu" doesn't serve any purpose and "dch -i"
will increase it to "ubuntu1", which is not exactly what we want for
native packages.
>> We could recommend avoiding native packages for Ubuntu-only packages.
>> This makes it easier for Debian to adopt the package, makes versioning
>> and backports simpler. For example I did this change for Apport and I do
>> not regret it.
>>
>> Alternative ideas:
>>
>> 1. Add `ubuntu` instead of `ubuntu0` as suffix to make it more obvious
>> what is going on. I would less likely change `1ubuntu` into `1ubuntu1`
>> than `1ubuntu0` into `1ubuntu1` (taking the example from Julian).
>
> I like this proposal since it could be adopted/tested without disrupting
> the current versioning models of our existing native packages.
But (compared to the above) "dch -i" in this pure "ubuntu" case produces a
"ubuntuubuntu1" version string, which is even worse than the "ubuntu1" above.
It makes obvious that something is wrong, but makes automation harder.
>> 2. Use `0ubuntu[version]` instead of `[version]ubuntu0`.
This variation fixes the "dch -i" and automation usecases by bumping it to
0ubuntuVERSION+1, i.e. the correct thing to do for native packages, but it
is a very unusual and non-intuitive version sting that would most probably
confuse developers looking at it. – It would confuse me and I'd likely
nitpick about it during a review.
So in summary, I feel like each variation has its own drawbacks, with
"ubuntu0" (while not ideal) being the most intuitive and pragmatic approach.
Cheers,
Lukas
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
