X-Original-To: alpine-devel@lists.alpinelinux.org
Delivered-To: alpine-devel@mail.alpinelinux.org
Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54])
	(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
	(No client certificate requested)
	by mail.alpinelinux.org (Postfix) with ESMTPS id E11A4DC00D8
	for <alpine-devel@lists.alpinelinux.org>; Tue, 30 Oct 2012 13:23:57 +0000 (UTC)
Received: by mail-pb0-f54.google.com with SMTP id rp8so204477pbb.13
        for <alpine-devel@lists.alpinelinux.org>; Tue, 30 Oct 2012 06:23:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=from:reply-to:to:subject:date:user-agent:references:in-reply-to:cc
         :mime-version:content-type:content-transfer-encoding:message-id;
        bh=UeQo6WS1CLj2723VxSyW33zEtoK+KziLqhyg1s3jgVY=;
        b=j+IXhuoaveePLrqI+FA/B0+cg9KMCf35fsjo9ucNCqxaAAW4liLq0UKnj9imEIBM1n
         f2POZgQZzsfg96fbuGJI78+B4ZoDIECrYXje6HIM2HzjrGP8PDWThRA60KhSffQksOS6
         469DWI3b8s8aRHN0TgK73osHh18KVnAYjmTVg2iOGBTx1DhXBXbmhutlLJE3mX0MUHK8
         34uHns4sV9LqFSmHIyL2NU+en1ATgESF9KIcpSRnUz2eunEqevHwl/kcSDbNaGT86xzQ
         g93SO1nEVTqL/vC3G65RUM6jR9F4r8emBXUoa1P3CtCLKVMdImjuAvIAqtAT56QjKOiV
         M6tQ==
Received: by 10.66.86.165 with SMTP id q5mr92125880paz.18.1351603436460;
        Tue, 30 Oct 2012 06:23:56 -0700 (PDT)
Received: from microknoppix.localnet ([117.227.65.226])
        by mx.google.com with ESMTPS id c7sm410730pay.10.2012.10.30.06.23.46
        (version=TLSv1/SSLv3 cipher=OTHER);
        Tue, 30 Oct 2012 06:23:54 -0700 (PDT)
From: "V.Krishn" <vkrishn4@gmail.com>
Reply-To: vkrishn4@gmail.com
To: Timo Teras <timo.teras@iki.fi>
Subject: Re: [alpine-devel] Questions about apk CMD -U
Date: Tue, 30 Oct 2012 18:50:23 +0530
User-Agent: KMail/1.13.7 (Linux/3.3.7-64; KDE/4.7.4; x86_64; ; )
References: <20121029181737.GB16841@vaio.jimpryor.net> <201210301738.57593.vkrishn4@gmail.com> <20121030142314.742ff63f@vostro>
In-Reply-To: <20121030142314.742ff63f@vostro>
Cc: alpine-devel@lists.alpinelinux.org
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="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201210301850.23343.vkrishn4@gmail.com>

On Tuesday, October 30, 2012 05:53:14 PM you wrote:
> 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?

 foo-1.2.3_my3-r2.1

here 'my' is the packager
Note: predefined suffix _cvs, _svn etc are prefixed to packager 'name'

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

-rN.<MY-VERSION> , here number after dot would make it easier to know the 
weight as compared to base/orig package.

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

Its position in name is just suggestive.

 foo-1.2.3-r2.1-my3 perhaps?

-- 
Regards.
V.Krishn

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