Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.devel > #112326 > unrolled thread

Re: Q: Ubuntu PPA induced version ordering mess.

Back to article view | Back to linux.debian.devel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Q: Ubuntu PPA induced version ordering mess. Scott Kitterman <debian@kitterman.com> - 2024-07-02 00:40 +0200
    Re: Q: Ubuntu PPA induced version ordering mess. Scott Kitterman <debian@kitterman.com> - 2024-07-02 01:00 +0200
      Re: Q: Ubuntu PPA induced version ordering mess. Scott Kitterman <debian@kitterman.com> - 2024-07-02 01:20 +0200
        Re: Q: Ubuntu PPA induced version ordering mess. Soren Stoutner <soren@debian.org> - 2024-07-02 01:40 +0200
          Re: Q: Ubuntu PPA induced version ordering mess. Soren Stoutner <soren@debian.org> - 2024-07-02 02:10 +0200
            Re: Q: Ubuntu PPA induced version ordering mess. Soren Stoutner <soren@debian.org> - 2024-07-02 02:30 +0200
              Re: Q: Ubuntu PPA induced version ordering mess. Scott Kitterman <debian@kitterman.com> - 2024-07-02 02:40 +0200
          Re: Q: Ubuntu PPA induced version ordering mess. Russ Allbery <rra@debian.org> - 2024-07-02 02:20 +0200
            Re: Q: Ubuntu PPA induced version ordering mess. Holger Levsen <holger@layer-acht.org> - 2024-07-02 12:10 +0200
          Re: Q: Ubuntu PPA induced version ordering mess. Jens Reyer <jens.reyer@gmail.com> - 2024-07-02 07:00 +0200
          Re: Q: Ubuntu PPA induced version ordering mess. Gunnar Wolf <gwolf@debian.org> - 2024-07-02 20:50 +0200
            Re: Q: Ubuntu PPA induced version ordering mess. Philip Hands <phil@hands.com> - 2024-07-03 10:20 +0200
              Re: Q: Ubuntu PPA induced version ordering mess. Holger Levsen <holger@layer-acht.org> - 2024-07-03 12:30 +0200
        Re: Q: Ubuntu PPA induced version ordering mess. Scott Kitterman <debian@kitterman.com> - 2024-07-02 01:40 +0200

#112326 — Re: Q: Ubuntu PPA induced version ordering mess.

On July 1, 2024 10:18:07 PM UTC, Alec Leamas <leamas.alec@gmail.com> wrote:
>On 02/07/2024 00:10, Scott Kitterman wrote:
>
>Hi Scott,
>
>> Upstream can change the versioning however they want.  They are upstream.  If
>> they don't care to fix it, then I think we assume they are fine with it and
>> leave it as is.
>
>
>But here the situation is that upstream do care and wants to fix it. But they need our help (an epoch) to accomplish this to handle the legacy.
>
>We could be helpful, or not. Why not give a hand?
>

No.  That's us fixing it.  They can bump the version to whatever they want to address the issue.  Epochs are forever, so should be a last resort.

Scott K

[toc] | [next] | [standalone]

#112327

[Multipart message — attachments visible in raw view] — view raw

On Monday, July 1, 2024 6:46:06 PM EDT Alec Leamas wrote:
> On 02/07/2024 00:31, Scott Kitterman wrote:
> 
> HI again
> 
> > On July 1, 2024 10:18:07 PM UTC, Alec Leamas <leamas.alec@gmail.com> 
wrote:
> >> But here the situation is that upstream do care and wants to fix it. But
> >> they need our help (an epoch) to accomplish this to handle the legacy.
> >> 
> >> We could be helpful, or not. Why not give a hand?
> > 
> > No.  That's us fixing it.  They can bump the version to whatever they want
> > to address the issue.  Epochs are forever, so should be a last resort.
> Yes, epochs are forever and should not be taken lightly, agreed.
> 
> Expanding on the situation. The current opencpn version is 5.9.x, soon
> to be 5.10 in a tick-tock cycle.
> 
> However, the opencpn packages have versions like 8763.x, automatically
> generated from a build number. This is not communicated to users, they
> just install and update.
> 
> Obviously, upstream should start building packages with versions like
> 5.9.x..., 5.10.x... etc. But any such version is lower than the current
> build number.
> 
> If you switch hats for a moment: have you any advice for upstream in
> this situation?
> 
> --alec
8763.5.10

Next build is:

8763.5.10~8764

Scott K

[toc] | [prev] | [next] | [standalone]

#112328

[Multipart message — attachments visible in raw view] — view raw

On Monday, July 1, 2024 7:07:16 PM EDT Alec Leamas wrote:
> On 02/07/2024 00:54, Scott Kitterman wrote:
> > On Monday, July 1, 2024 6:46:06 PM EDT Alec Leamas wrote:
> >> If you switch hats for a moment: have you any advice for upstream in
> >> this situation?
> > 
> > 8763.5.10
> 
> Yes, I have had a similar idea using 10000 instead of 8763 to make it
> stand out less. In my eyes, this is worse and will lead to that the
> package versions does not match the "public" version like 5.10.2.
> 
> But if the list agrees that this is the correct solution so be it. To be
> honest, it might be a hard sell upstream.
> 
> > Next build is:
> > 
> > 8763.5.10~8764
> 
> Why?
> 
> --alec

Because the '~' means less than.  It's a way to add the build number to the 
interim versions in the future without causing the same problem again.  I 
guess it should have been 8763.5.11~8764, if 5.11 is the next 'real' version.

Scott K

[toc] | [prev] | [next] | [standalone]

#112329

[Multipart message — attachments visible in raw view] — view raw

Alec,

On Monday, July 1, 2024 4:19:22 PM MST Alec Leamas wrote:
> Hi again
> 
> On 02/07/2024 01:13, Scott Kitterman wrote:
> > On Monday, July 1, 2024 7:07:16 PM EDT Alec Leamas wrote:
> >> On 02/07/2024 00:54, Scott Kitterman wrote:
> >>> On Monday, July 1, 2024 6:46:06 PM EDT Alec Leamas wrote:
> >>>> If you switch hats for a moment: have you any advice for upstream in
> >>>> this situation?
> >>> 
> >>> 8763.5.10
> >> 
> >> Yes, I have had a similar idea using 10000 instead of 8763 to make it
> >> stand out less. In my eyes, this is worse and will lead to that the
> >> package versions does not match the "public" version like 5.10.2.
> >> 
> >> But if the list agrees that this is the correct solution so be it. To be
> >> honest, it might be a hard sell upstream.
> >> 
> >>> Next build is:
> >>> 
> >>> 8763.5.10~8764
> >> 
> >> Why?
> >> 
> >> --alec
> > 
> > Because the '~' means less than.  It's a way to add the build number to 
the
> > interim versions in the future without causing the same problem again.  I
> > guess it should have been 8763.5.11~8764, if 5.11 is the next 'real'
> > version.
> 
> There is absolutely no need of build numbers in the version, it's just a
> sad legacy.
> 
> Let's drop this subthread, keeping eyes on the ball: what is a sane version?
> 
> --a

If upstream wants to fix this problem, they could just make their next release 
version 9000, with the one after that either being 9001 or 9000.1.

Or, possibly, they could encourage everyone to uninstall the PPA package 
before installing an official one.  For example, release a new package to their 
PPA that displays a message encouraging everyone to uninstall the PPA package, 
remove the PPA from their list of repositories, and *then* install the official 
one.

As a general rule, I wouldn’t expect a user to keep a PPA package installed 
when switching to an official package.  There is generally no guarantee that 
upgrading from a PPA package to an official one will work without errors.

Or, once the official package had entered the system, they could instruct users 
to remove the PPA from their list of repositories and then perform a 
downgrade.

All of that being said, Debian could use an epoch to fix the problem.  Having 
an epoch on a package isn’t the worst thing that has ever happened.

-- 
Soren Stoutner
soren@debian.org

[toc] | [prev] | [next] | [standalone]

#112333

[Multipart message — attachments visible in raw view] — view raw

Alec,

On Monday, July 1, 2024 4:59:26 PM MST Alec Leamas wrote:
> 1. Persuade users to uninstall PPA packages before installing official
> packages and also generation 2 PPA packages with sane versions like 5.10.x

[...]

> Of these I would say that 1. is a **very** hard sell upstream. Users are
> used to just update and will try, fail and cause friction.

Although I generally agree with your conclusions, using a PPA is the type of 
end user task that involved them making modifications to the repositories on 
their systems.  I would assume that anyone who has done so, and who is already 
running Linux instead of Windows, is fully capable of handling a “downgrade” 
to an official package.  Asking users to remove the PPA they manually added and 
install an official package doesn’t really seem like that hard of an ask to me.

-- 
Soren Stoutner
soren@debian.org

[toc] | [prev] | [next] | [standalone]

#112336

[Multipart message — attachments visible in raw view] — view raw

Alec,

On Monday, July 1, 2024 5:19:37 PM MST Alec Leamas wrote:
> For Debian users we backport opencpn which works well. However, the
> Ubuntu backport process is, well, interesting (been there, done that).
> 
> The PPA represents a much better way to publish backports to current
> Ubuntu branches. But for this to work we need to reset the versioning so
> it works together with the official stream from Debian.
> 
> Anyway, seems we have a emerging conclusion that an epoch is a correct
> solution here.

That adds some needed clarification.  I agree that in that circumstance, adding 
an epoch is the best way forward.  It allows you to maintain the current 
upstream program version number, while unifying the Debian, Ubuntu, and PPA 
version numbers in such a way that packages from those repositories can be 
used interchangeably.

-- 
Soren Stoutner
soren@debian.org

[toc] | [prev] | [next] | [standalone]

#112337

On July 2, 2024 12:26:49 AM UTC, Soren Stoutner <soren@debian.org> wrote:
>Alec,
>
>On Monday, July 1, 2024 5:19:37 PM MST Alec Leamas wrote:
>> For Debian users we backport opencpn which works well. However, the
>> Ubuntu backport process is, well, interesting (been there, done that).
>> 
>> The PPA represents a much better way to publish backports to current
>> Ubuntu branches. But for this to work we need to reset the versioning so
>> it works together with the official stream from Debian.
>> 
>> Anyway, seems we have a emerging conclusion that an epoch is a correct
>> solution here.
>
>That adds some needed clarification.  I agree that in that circumstance, adding 
>an epoch is the best way forward.  It allows you to maintain the current 
>upstream program version number, while unifying the Debian, Ubuntu, and PPA 
>version numbers in such a way that packages from those repositories can be 
>used interchangeably.
>
I would suggest that you work with upstream on how they will version things in the future, so you aren't bumping the epoch every year.

Scott K

[toc] | [prev] | [next] | [standalone]

#112335

Alec Leamas <leamas.alec@gmail.com> writes:

> So, at least three possible paths:

> 1. Persuade users to uninstall PPA packages before installing official
> packages and also generation 2 PPA packages with sane versions like
> 5.10.x

> 2. Use versions like 9000.5.10, 9000.5.12. etc.

> 3. Use an epoch.

> Of these I would say that 1. is a **very** hard sell upstream. Users are
> used to just update and will try, fail and cause friction.

> 2. and 3. both adds something which must be kept forever. Given this
> choice I tend to think that the epoch is the lesser evil, mostly because
> the package version could match the "real" version.

I would use an epoch.

It sounds like the PPA was in serious use by the intended users and
they're going to be switching to your packages.  You are trying to make
that easy and avoid obvious and easily-forseen problems and I think that's
good: that's exactly what a maintainer should do.  If it were just a
handful of people you could walk through the transition, that's maybe
different, but it sounds like that's not the case.

2 is a hard sell to upstream for psychological reasons.  Maybe it
shouldn't be, maybe upstream should be fine with this, but as you say
upstream in practice isn't going to be fine with this and honestly if I
were upstream I probably wouldn't be either, even if I knew I should be.
It's hard enough to get people to use version numbers properly.  Getting
them to use a "weird" version number that their users might be confused by
for the rest of time is going to be difficult.

Changing the version number only in Debian is even worse: that's just
horribly confusing for users and will be forever.  And the confusion is
going to affect upstream as well.

Basically, you'd be burning a lot of social capital with upstream for no
really good reason and you probably still wouldn't be able to convince
them.  I don't think it's worth it.

I would just use the epoch.  I know people really hate them and they have
a few weird and annoying properties, but we have a bunch of packages with
epochs and it's mostly fine.  It's something you'll have to keep working
around forever, but not in a way that's really that hard to deal with,
IMO.  (I would also warn upstream that you're doing that, so that they
know what the weird "1:" thing means in bug reports in the future and why
it's there.)

This feels like exactly the type of situation that epochs were designed
for: upstream was releasing packages with weird version numbers and now
they're effectively going back to normal version numbers that are much
smaller.  In other words, to quote policy, "situations where the upstream
version numbering scheme changes."  Yes, in this case it was only in their
packages and not in their software releases, but that still counts when
they have an existing user base that has those packages installed.

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]

#112346

[Multipart message — attachments visible in raw view] — view raw

On Mon, Jul 01, 2024 at 05:17:09PM -0700, Russ Allbery wrote:
> I would use an epoch.

yes.
 
[...]
> Basically, you'd be burning a lot of social capital with upstream for no
> really good reason and you probably still wouldn't be able to convince
> them.  I don't think it's worth it.

yes.

> I would just use the epoch.  I know people really hate them and they have
> a few weird and annoying properties, but we have a bunch of packages with
> epochs and it's mostly fine. 

a bunch?

$ grep ^Version: /var/lib/apt/lists/deb.debian.org_debian_dists_unstable_main_source_Sources |awk ' { print $2 } ' |grep -c :
1142
$ grep -c ^Version: /var/lib/apt/lists/deb.debian.org_debian_dists_unstable_main_source_Sources
38200

ok, maybe 3% of all packages is a bunch. :)

> It's something you'll have to keep working
> around forever, but not in a way that's really that hard to deal with,
> IMO.

yes.

> This feels like exactly the type of situation that epochs were designed
> for: upstream was releasing packages with weird version numbers and now
> they're effectively going back to normal version numbers that are much
> smaller.  In other words, to quote policy, "situations where the upstream
> version numbering scheme changes."  Yes, in this case it was only in their
> packages and not in their software releases, but that still counts when
> they have an existing user base that has those packages installed.

yes.

Thank you Russ, for wording this so well, that I don't have to type much.


-- 
cheers,
	Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

In a world where you can be anything, be kind.

[toc] | [prev] | [next] | [standalone]

#112342

[Multipart message — attachments visible in raw view] — view raw

Am 2. Juli 2024 01:59:26 MESZ schrieb Alec Leamas <leamas.alec@gmail.com>:
>Soren et. al.,
>
>On 02/07/2024 01:31, Soren Stoutner wrote:
>> Alec,
>> 
>> 
>> If upstream wants to fix this problem, they could just make their next release
>> version 9000, with the one after that either being 9001 or 9000.1.
>> 
>> Or, possibly, they could encourage everyone to uninstall the PPA package
>> before installing an official one.  For example, release a new package to their
>> PPA that displays a message encouraging everyone to uninstall the PPA package,
>> remove the PPA from their list of repositories, and *then* install the official
>> one.
>> 
>> As a general rule, I wouldn’t expect a user to keep a PPA package installed
>> when switching to an official package.  There is generally no guarantee that
>> upgrading from a PPA package to an official one will work without errors.
>> 
>> Or, once the official package had entered the system, they could instruct users
>> to remove the PPA from their list of repositories and then perform a
>> downgrade.
>> 
>> All of that being said, Debian could use an epoch to fix the problem.  Having
>> an epoch on a package isn’t the worst thing that has ever happened.
>> 
>So, at least three possible paths:
>
>1. Persuade users to uninstall PPA packages before installing official packages and also generation 2 PPA packages with sane versions like 5.10.x
>
>2. Use versions like 9000.5.10, 9000.5.12. etc.
>
>3. Use an epoch.
>
>Of these I would say that 1. is a **very** hard sell upstream. Users are used to just update and will try, fail and cause friction.
>
>2. and 3. both adds something which must be kept forever. Given this choice I tend to think that the epoch is the lesser evil, mostly because the package version could match the "real" version.
>
>That is, the idea that next opencpn release officially would be 9000.5.10 just won't fly. 2. would be about using package versions with a number prefix like 9000. which is not really visible to users.  And that means an impedance problem between the upstream version and the packaged one. A problem the epoch does not have.
>
>--alec
>

[Currently on my phone with no direct access to my Debian mail jre.winesim@gmail.com, but annoying autocorrect and topposting instead]

You may avoid the epoch if upstream is willing to provide a separate package for about 2 years. (I did something similar to get rid of an epoch in Ubuntu's wine packages a few years ago, replacing them with our Debian packages):

package 9000.5.10
Depends: package-transition-to-new-versioning

package-transition-to-new-versioning 5.9.2-1


In 2 years:
package-transition-to-new-versioning 5.9.2-2
Depends: package 5.9.2-2

You'll also need some breaks/replaces in Debian's packages.

I might dig out the details later if your interested.

[toc] | [prev] | [next] | [standalone]

#112350

Alec Leamas dijo [Tue, Jul 02, 2024 at 01:59:26AM +0200]:
> So, at least three possible paths:
> 
> 1. Persuade users to uninstall PPA packages before installing official
> packages and also generation 2 PPA packages with sane versions like 5.10.x
> 
> 2. Use versions like 9000.5.10, 9000.5.12. etc.
> 
> 3. Use an epoch.

You can also consider a third possible path: Pick a different package
name.

I am unfamiliar with opencpn to be able to suggest an alternative. But
given opencpn has never been part of Debian, you could just name your
package "opencpn-deb". Just to be sure users don't get surprised by
having two different versions of the same package, it can "Conflict:
opencpn". Then, you get a blank slate from which you can work your
versioning as you deem adequate.

It does, yes, introduce some confusion, but I think is the least evil
option. 

[toc] | [prev] | [next] | [standalone]

#112353

[Multipart message — attachments visible in raw view] — view raw

Alec Leamas <leamas.alec@gmail.com> writes:

> On 02/07/2024 20:46, Gunnar Wolf wrote:
>> Alec Leamas dijo [Tue, Jul 02, 2024 at 01:59:26AM +0200]:
>>> So, at least three possible paths:
>>>
>>> 1. Persuade users to uninstall PPA packages before installing official
>>> packages and also generation 2 PPA packages with sane versions like 5.10.x
>>>
>>> 2. Use versions like 9000.5.10, 9000.5.12. etc.
>>>
>>> 3. Use an epoch.
>> 
>> You can also consider a third possible path: Pick a different package
>> name.
>> 
>> I am unfamiliar with opencpn to be able to suggest an alternative. But
>> given opencpn has never been part of Debian, you could just name your
>> package "opencpn-deb". Just to be sure users don't get surprised by
>> having two different versions of the same package, it can "Conflict:
>> opencpn". Then, you get a blank slate from which you can work your
>> versioning as you deem adequate.
>> 
>> It does, yes, introduce some confusion, but I think is the least evil
>> option.
>
> opencpn is part of Debian since many years. However, the major 
> distribution is through an Ubuntu PPA, the official Debian package is 
> not that visible and of course outdated in Ubuntu.
>
> opencpn users are counted in at least thousands. We are trying to 
> convince the developer community that it's a good idea to use a package 
> created as an official Debian package  rather than an auto-generated 
> cmake package distributed using the Ubuntu PPA.

If someone has gone to the effort of configuring a PPA source, it seems
slightly abusive to try and override that choice by playing games with
versions.

If you do that, and the user has any problem as a result, then the user
may be upset enough to "downgrade" to the PPA and pin it, which will
burn their goodwill towards Debian, and further entrench the problem you
are trying to fix.

Alternatively, the PPA maintainer may just adopt the epoch:upstream
version now that they are aware of the problem, and then the user gets
to flap back and forth between versions from Debian and the PPA as new
versions come out and are packaged at differing rates.

It seems better to take an "If we build it, they will come" approach.
New installs will likely get the Debian version without ever needing to
discover the PPA, and the rumour will spread (assuming the Debian
package works at least as well) that there's no need to bother with the
PPA, and then people will do the work to remove the PPA from their
configs, at a time of their choosing.

Might it be worth chatting to the PPA maintainer to see it they'd like
to be included in the effort to maintain the Debian package? They may
discover that it's less effort for all involved doing it as a team.

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil

[toc] | [prev] | [next] | [standalone]

#112355

[Multipart message — attachments visible in raw view] — view raw

hi Alec,

please stop mailing this thread and just use an epoch.

Before adding^wintroducing an epoch one should consult debian-devel@l.d.o,
you have done this, arguments were exchanged and (IMNSHO) no better
solution was found, so please do what has done to >1000 source packages
in the archive already, and add an epoch.

Thanks for caring about free software and it's users.


-- 
cheers,
	Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

"A fundamentalist gender binary was a key feature of Nazi racial politics and
 genocide. (...) It must be said that the reality of transgender identity
 cannot be challenged. Transgender people have existed throughout history."
https://www.lemkininstitute.com/statements-new-page/statement-on-the-genocidal-nature-of-the-gender-critical-movement%E2%80%99s-ideology-and-practice

[toc] | [prev] | [next] | [standalone]

#112330

On July 1, 2024 11:25:59 PM UTC, Alec Leamas <leamas.alec@gmail.com> wrote:
>On 02/07/2024 01:19, Alec Leamas wrote:
>
>> Let's drop this subthread, keeping eyes on the ball: what is a sane version?
>
>Looking at this from another point of view: is there any situation where an epoch is appropriate?

Yes.  I don't think this is it.

A sane version is one that's higher than the last one.  If upstream wants the last one to include their versioning from non-Debian packages, they can do that.  If they don't want to, that's fine, but I don't think we should either then.

Scott K

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.devel

csiph-web