Date: Fri, 6 Apr 2012 16:22:27 +0200
From: Natanael Copa <ncopa@alpinelinux.org>
To: Timo Teras <timo.teras@iki.fi>
Cc: Kiyoshi Aman <aphrael@alpinelinux.org>,
 alpine-devel@lists.alpinelinux.org
Subject: Re: [alpine-devel] APK version formats
Message-ID: <20120406162227.160d0426@alpinelinux.org>
In-Reply-To: <20120406160622.2db84f05@vostro>
References: <CAML-Udub-YusXQ6xMJyWo6jMvnHO5V3u4FkkywSncPFvwfjNKg@mail.gmail.com>
	<20120406160622.2db84f05@vostro>
Precedence: list
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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
---