X-Original-To: alpine-devel@lists.alpinelinux.org
Delivered-To: alpine-devel@mail.alpinelinux.org
Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54])
	(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
	(No client certificate requested)
	by mail.alpinelinux.org (Postfix) with ESMTPS id D4BBCDC00CD
	for <alpine-devel@lists.alpinelinux.org>; Tue, 30 Oct 2012 12:24:32 +0000 (UTC)
Received: by mail-bk0-f54.google.com with SMTP id jf20so137929bkc.13
        for <alpine-devel@lists.alpinelinux.org>; Tue, 30 Oct 2012 05:24:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=sender:date:from:to:cc:subject:message-id:in-reply-to:references
         :x-mailer:mime-version:content-type:content-transfer-encoding;
        bh=4QNHhg3/4iZmOko4jpbtwR0Ngc0NdQJ+j4zA9VYE7Jo=;
        b=rhKL1lO078VD+NS2/jY51BB+iH4j2ewO1LCPhti3tnpfCV+k6iQNOqy6I2iOO+DEi3
         oPja4YTdwT5se/ije8frnoqdV/hMBIglpVsAxS1+96+JXNgcf96uZ+tZjfPz/0Dk3/da
         cziPJAf5QzptgAoe9XrR68iX2d6NoZibTTneElw5mnU6wj+actnCKtmPbs/yLM8rEuvA
         rOALzYIbpmUO4buahYhrrgC1zGxLDbuYNxj0AGIG73fXveBzWKZrgAYvUZRONzf7NUOx
         3d2Z/w78js5cob4oyZltnXxpvDwdh4FjwJ4yoADZaIqSNn5QoQ1mm5zf/p1mU/1Wvfd8
         4tsw==
Received: by 10.204.4.75 with SMTP id 11mr10071395bkq.96.1351599871086;
        Tue, 30 Oct 2012 05:24:31 -0700 (PDT)
Received: from vostro ([2001:1bc8:101:f402:21c:23ff:fefc:bf0b])
        by mx.google.com with ESMTPS id j24sm835750bkv.0.2012.10.30.05.24.29
        (version=SSLv3 cipher=OTHER);
        Tue, 30 Oct 2012 05:24:30 -0700 (PDT)
Sender: =?UTF-8?Q?Timo_Ter=C3=A4s?= <timo.teras@gmail.com>
Date: Tue, 30 Oct 2012 14:23:14 +0200
From: Timo Teras <timo.teras@iki.fi>
To: vkrishn4@gmail.com
Cc: alpine-devel@lists.alpinelinux.org
Subject: Re: [alpine-devel] Questions about apk CMD -U
Message-ID: <20121030142314.742ff63f@vostro>
In-Reply-To: <201210301738.57593.vkrishn4@gmail.com>
References: <20121029181737.GB16841@vaio.jimpryor.net>
	<201210301325.04001.vkrishn4@gmail.com>
	<20121030135427.78ec5489@vostro>
	<201210301738.57593.vkrishn4@gmail.com>
X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; i686-pc-linux-gnu)
X-Mailinglist: alpine-devel
Precedence: list
List-Id: Alpine Development <alpine-devel.lists.alpinelinux.org>
List-Unsubscribe: 
	<mailto:alpine-devel+unsubscribe@lists.alpinelinux.org?subject=unsubscribe>
List-Post: <mailto:alpine-devel@lists.alpinelinux.org>
List-Help: <mailto:alpine-devel+help@lists.alpinelinux.org?subject=help>
List-Subscribe: 
	<mailto:alpine-devel+subscribe@lists.alpinelinux.org?subject=subscribe>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Tue, 30 Oct 2012 17:38:57 +0530 "V.Krishn" <vkrishn4@gmail.com>
wrote:

> On Tuesday, October 30, 2012 05:24:27 PM you wrote:
> > On Tue, 30 Oct 2012 13:25:03 +0530 "V.Krishn" <vkrishn4@gmail.com>
> > 
> > wrote:
> > > > Perhaps we should fix the -rN field to allow decimal point for
> > > > "customized" builds or similar, like '-r1.1'. Any opinions on
> > > > this? Or any other ideas?
> > > 
> > > How does _pN suffix get applied?
> > 
> > It is part of the version string. Before -rN, but after the version.
> > E.g. 1.2.3_p1-r0.
> > 
> > > I mean , can it be any _<text>N?
> > 
> > No.
> > 
> > Currently apk-tools handles: _cvs, _svn, _git, _hg, _p as "post"
> > version suffixes. Meaning they are considered higher version numbers
> > than if the version was without any suffix.
> > 
> > Additionally, suffixes: _alpha, _beta, _pre and _rc are considred
> > "pre" version suffixes, and considered as lesser version numbers as
> > the same version without any suffix.
> > 
> > > if not then '-r1.1' may not be very helpful, coz package name
> > > should indentify the packager in someway.
> > 
> > The problem with version numbers is that we need a way to identify
> > which is greater and which is lesser in unambiguous way.
> 
> Just a thought:
> 
> eg.
>  foo-1.2.3-r2
>  foo-1.2.3_my2-r2.1 <- latest
> 
> eg.
>  foo-1.2.3-r2
>  foo-1.2.3_my2-r3.1
>  foo-1.2.3_my3-r3.1 <- latest
> 
> eg.
>  foo-1.2.3-r4 <- latest
>  foo-1.2.3_my2-r3.1
>  foo-1.2.3_my3-r2.1
> 
> eg.
>  foo-1.2.3_my2-r3.1
>  foo-1.2.3_my3-r2.1 <- latest
> 
> whole thing should work on assumption that
> presence of any suffix should only be considered new if its root foo-
> <version>-<rev>N are same or greater.
> In absence of root package both suffixN and rN are evaluated.

So how does this differ from -r1.1 thing?

The idea was that Alpine would use -rN (where n does not contain dot)
only. And would leave the customized packages to use "-rN.<MY-VERSION>"
syntax.

I do not see point in allowing any random strings, as we could not
really make good separation on them. And suffixing the "_myX"
before "-rN" confuses as it would be sorted in non-logical order.

I wonder if we want some package "flavor" string added to the package
name which does not affect version sorting, but would just have
informative purpose. I would prefer not - and just make people learn
the repository pinning.

In general - it seems we should be going more for "packages come from
certain repository" and sort them accordingly, even if it means
downgrading -- instead of "try to figure out universal versioning
scheme for package so that include also the builder info etc". The fact
is that packages alone do not work - their dependencies must come from
same place too.

I'm actually getting tempted to ignore the package version altogether
in the package (store it for display only) -- and just store the
repository commit date in the package and use it as the version test.
And then have some way to specify what is the preferred order of
repositories. This would make things a lot easier - and allow easy
downgrading in case some package needs to be downgraded (without stupid
hacks like Debian epoch version notation).

- Timo


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---