Subject: [alpine-devel] APK version formats

From: Kiyoshi Aman <[email-masked]>
Date: Fri, 6 Apr 2012 07:39:54 -0400

Hi folks,

Would it be possible for apk-tools' versioning code to be adapted to
support underscores? Such version numbers are unfortunately common,
e.g. for RCs and on Perl modules such as ExtUtils::MakeMaker.
Moreover, most other package managers do support these version
numbers. I look forward to working with you folks on this matter.

--Kiyoshi Aman

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---

---

From: Natanael Copa <[email-masked]>
Date: Fri, 6 Apr 2012 16:21:54 +0200

On Fri, 6 Apr 2012 07:39:54 -0400

> numbers. I look forward to working with you folks on this matter.

This will break things. Please lets focus on making v2.4 release first.

-nc

---

---

From: Timo Teras <[email-masked]>
Date: Fri, 6 Apr 2012 16:06:22 +0300

Hi,

> numbers. I look forward to working with you folks on this matter.

For others, we discussed this shortly in irc earlier; and the proposal
is to accept version numbers "1.2.3_01" which are currently considered
invalid. I also thought 1.2.3_rc1 is invalid, but that in fact is
currently valid. However, 1.2.3-rc1 is invalid.

I believe this is legacy of using in the dawn of time emerge and
portage to do building. And (at least at the time) the underscore was
not considered valid in versions.

The current rule is that version is something like:
 {digit}{.digit}...{letter}{_suf{#}}...{-r#}

Suffixes go into two categories "pre" and "post" version suffixes.

"pre" versions are "alpha", "beta", "pre", "rc" and a version with any
of these suffixes get sorted as earlier or lower than version without
the suffix.

"post" versions are "cvs", "svn", "git", "hg", "p" and get sorted later
than or greater than version without suffix.

I generally have no objection of handling empty string as "post"
suffix. Assuming that's ok with ncopa and others. I think we should not
have anything using Gentoo heritage anymore, so this should be safe
change.

Though, currently we do not support -rc1; and I'd prefer to keep this
that way. 1.2.3-rc1-r1 might be confusing.

So the question is with 1.2.3_01 versions if it's more trouble to
mangle them (to 1.2.3.01; 1.2.3_p01; or similar) without causing too
much trouble. Or if we should just accept 1.2.3_01 as-is. At least it
would not cause any problems to sort them properly.

Thoughts?

- Timo

---

---

From: Kiyoshi Aman <[email-masked]>
Date: Fri, 6 Apr 2012 09:15:19 -0400

> would not cause any problems to sort them properly.

Personally, I think that manually mangling version numbers is
inappropriate. In addition to the above proposal, I'd also like to
recommend that apk-tools itself mangle oddball version numbers so the
APKBUILD can always contain the true and correct version number.

--Kiyoshi Aman

---

---

From: Timo Teras <[email-masked]>
Date: Fri, 6 Apr 2012 16:46:41 +0300

On Fri, 6 Apr 2012 09:15:19 -0400 Kiyoshi Aman <[email-masked]>
wrote:

> > much trouble. Or if we should just accept 1.2.3_01 as-is. At least
> > it would not cause any problems to sort them properly.
> 

No. Currently apk-tools needs to be able to compare two version
numbers, and make a rational choice which one is better. Just blindly
mangling something makes this break.

Alternative is that we change version to be just a 'display version';
and keep the apk-tools version separate thing. I believe it was earlier
suggested that we could just use the package source repository and
build timestamp to decide which package is the preferred one. In this
case we could just dump whatever garbage in the version field, ignore
it, and figure out the preferred package from better fields.

---

---

From: Kiyoshi Aman <[email-masked]>
Date: Fri, 6 Apr 2012 10:24:53 -0400

> it, and figure out the preferred package from better fields.

Having a display version which can contain whatever would be ideal,
yes, provided it can be mapped to the internal version apk-tools
expects without causing problems.

---

---

From: Natanael Copa <[email-masked]>
Date: Fri, 6 Apr 2012 16:34:44 +0200

On Fri, 6 Apr 2012 16:46:41 +0300
Timo Teras <[email-masked]> wrote:

> and keep the apk-tools version separate thing. I believe it was
> earlier suggested that we could just use the package source
> repository and build timestamp to decide which package is the
> preferred one. In this case we could just dump whatever garbage in
> the version field, ignore it, and figure out the preferred package
> from better fields.

I have mixed feelings about this. It would be nice to have git hashes
as the version string, but I think that things will end up
unpredictable for end users.

User has both main and testing in repositories. The main has stable
foo-1.0.2 and testing has next, foo-2.0_beta1. The user has "testing"
in his repos because he wants the latest to test things early, even if
it breaks things once in a while. So he has foo-2.0_beta1 installed.

So comes a new bugfix release, foo-1.0.3 in main. What will the user
expect to happen? What will happen if we use build timestamp?

-nc

---

---

From: Natanael Copa <[email-masked]>
Date: Fri, 6 Apr 2012 16:26:52 +0200

On Fri, 6 Apr 2012 09:15:19 -0400

> APKBUILD can always contain the true and correct version number.

If you have a good algorithm that works on every single strange version
scheme out there please let us know. I don't believe it is possible
even in theory.

In any case, we should not work on that now. We should fixing bugs
and test things for v2.4 release.

-nc

---

---

From: Natanael Copa <[email-masked]>
Date: Fri, 6 Apr 2012 16:22:27 +0200

On Fri, 6 Apr 2012 16:06:22 +0300

> > numbers. I look forward to working with you folks on this matter.

Is this a needed for something or is it a convenience thing? I'm asking
because touching the rules *will* break things in one way or the other.
Some things that previously worked will no longer work and there will
be nasty corner cases we will have to deal with when it comes to
upgrades.

> not considered valid in versions.

Gentoo numbering requires that it is possible to separate version
number from package name from the file name (eg foo-1.0_rc1.ebuild). I
think this is a nice feature, even if we don't depend on it.

What is package name and what is version in those string:
ntfs-3g-2012.1.15-r0
tzdata-2012b-r0
iwlwifi-3945-ucode-15.32.2.9-r1

> "post" versions are "cvs", "svn", "git", "hg", "p" and get sorted
> later than or greater than version without suffix.
> 
> suffix. Assuming that's ok with ncopa and others. I think we should
> not have anything using Gentoo heritage anymore, so this should be
> safe change.

We will most likely lost the ability to separate package names from
version strings from apk tools output. (eg apk search '*'). We will
need change how package names and version strings are printed in
apk-tools first. Then we need update all current scripts that uses this.

> would not cause any problems to sort them properly.

I think this will cause much trouble and I think we need good reasons
for doing this. I am not saying that we shouldn't change it, just that
it is probably more work than you'd expect at first sight.

In any case. We are in April now. In the beginning of May we will do a
new stable release. We should focus on how to avoid bugs in this
release before talking on how to break next.

-nc

---