~alpine/devel

8 3

[alpine-devel] APK version formats

Details
Message ID
<CAML-Udub-YusXQ6xMJyWo6jMvnHO5V3u4FkkywSncPFvwfjNKg@mail.gmail.com>
Sender timestamp
1333712394
DKIM signature
missing
Download raw message
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:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Details
Message ID
<CAML-UdvATTNHzn_C2wuph5jKx1MAg5acJKJjqJTV0P5vqHsfOw@mail.gmail.com>
In-Reply-To
<20120406160622.2db84f05@vostro> (view parent)
Sender timestamp
1333718119
DKIM signature
missing
Download raw message
2012/4/6 Timo Teras <timo.teras@iki.fi>:
> 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.

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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Details
Message ID
<CAML-UdsKoLm3YpKN0_u7H0TaqR6fqUTvaSgCp61Dw10SjgG+5A@mail.gmail.com>
In-Reply-To
<20120406164641.6f7f7a74@vostro> (view parent)
Sender timestamp
1333722293
DKIM signature
missing
Download raw message
2012/4/6 Timo Teras <timo.teras@iki.fi>:
> 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.

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.


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Timo Teras <timo.teras@iki.fi>
Details
Message ID
<20120406160622.2db84f05@vostro>
In-Reply-To
<CAML-Udub-YusXQ6xMJyWo6jMvnHO5V3u4FkkywSncPFvwfjNKg@mail.gmail.com> (view parent)
Sender timestamp
1333717582
DKIM signature
missing
Download raw message
Hi,

On Fri, 6 Apr 2012 07:39:54 -0400 Kiyoshi Aman
<aphrael@alpinelinux.org> wrote:

> 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.

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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20120406162154.22e3e8c9@alpinelinux.org>
In-Reply-To
<CAML-Udub-YusXQ6xMJyWo6jMvnHO5V3u4FkkywSncPFvwfjNKg@mail.gmail.com> (view parent)
Sender timestamp
1333722114
DKIM signature
missing
Download raw message
On Fri, 6 Apr 2012 07:39:54 -0400
Kiyoshi Aman <aphrael@alpinelinux.org> wrote:

> 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.

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

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20120406162227.160d0426@alpinelinux.org>
In-Reply-To
<20120406160622.2db84f05@vostro> (view parent)
Sender timestamp
1333722147
DKIM signature
missing
Download raw message
On Fri, 6 Apr 2012 16:06:22 +0300
Timo Teras <timo.teras@iki.fi> wrote:

> Hi,
> 
> On Fri, 6 Apr 2012 07:39:54 -0400 Kiyoshi Aman
> <aphrael@alpinelinux.org> wrote:
> 
> > 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.

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.

> 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.

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


> 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.

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.

> 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?

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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20120406162652.71fb901e@alpinelinux.org>
In-Reply-To
<CAML-UdvATTNHzn_C2wuph5jKx1MAg5acJKJjqJTV0P5vqHsfOw@mail.gmail.com> (view parent)
Sender timestamp
1333722412
DKIM signature
missing
Download raw message
On Fri, 6 Apr 2012 09:15:19 -0400
Kiyoshi Aman <kiyoshi.aman@gmail.com> wrote:

> 2012/4/6 Timo Teras <timo.teras@iki.fi>:
> > 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.
> 
> 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.

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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20120406163444.59091f51@alpinelinux.org>
In-Reply-To
<20120406164641.6f7f7a74@vostro> (view parent)
Sender timestamp
1333722884
DKIM signature
missing
Download raw message
On Fri, 6 Apr 2012 16:46:41 +0300
Timo Teras <timo.teras@iki.fi> wrote:

> 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.

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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Timo Teras <timo.teras@iki.fi>
Details
Message ID
<20120406164641.6f7f7a74@vostro>
In-Reply-To
<CAML-UdvATTNHzn_C2wuph5jKx1MAg5acJKJjqJTV0P5vqHsfOw@mail.gmail.com> (view parent)
Sender timestamp
1333720001
DKIM signature
missing
Download raw message
On Fri, 6 Apr 2012 09:15:19 -0400 Kiyoshi Aman <kiyoshi.aman@gmail.com>
wrote:

> 2012/4/6 Timo Teras <timo.teras@iki.fi>:
> > 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.
> 
> 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.

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.


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Reply to thread Export thread (mbox)