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 5B226DC00D2
	for <alpine-devel@lists.alpinelinux.org>; Wed, 28 Nov 2012 09:54:00 +0000 (UTC)
Received: by mail-bk0-f54.google.com with SMTP id je9so5440655bkc.13
        for <alpine-devel@lists.alpinelinux.org>; Wed, 28 Nov 2012 01:53:59 -0800 (PST)
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=xahiwN2cJ+XArxeEKB31O+uZz+fPtGmXH9cGcNsE0KA=;
        b=YPIaUfU9NTTfe7DjwfoAJNMOMCBRjIJ5hnl3OMdiHnPjfj0NOxCxr8PTqcXjum/bLG
         6Wa0U9FRzdPaT5l/lxNz47PO7eiKslbKtIqRJ2QyJjDgpc60nGekIjC2TmzSmM4OP0VC
         7hPjJ9bJz59yi29CNJJFjnyfWwonEmWnIHfQImQdsqQrgyaq+VACVrt6CB5EMl1t3mIw
         nTJgyw+XV4gsL3FM1+g846Qfr3JlovGcFUi8MQP+49x9lqfCRrwffXZ9ZftzP/ZON0ff
         tfM6sTQEvEU3uj6wWNQ0mTewN3kxUrJ41jq02wWofq4KBRa9n91XDN8hMGY0c2iC8XEW
         ERbA==
Received: by 10.204.147.79 with SMTP id k15mr5285484bkv.55.1354096439100;
        Wed, 28 Nov 2012 01:53:59 -0800 (PST)
Received: from vostro ([2001:1bc8:101:f402:21c:23ff:fefc:bf0b])
        by mx.google.com with ESMTPS id y11sm12039947bkw.8.2012.11.28.01.53.57
        (version=SSLv3 cipher=OTHER);
        Wed, 28 Nov 2012 01:53:58 -0800 (PST)
Sender: =?UTF-8?Q?Timo_Ter=C3=A4s?= <timo.teras@gmail.com>
Date: Wed, 28 Nov 2012 11:53:17 +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: <20121128115317.333ba6a8@vostro>
In-Reply-To: <201211251425.18336.vkrishn4@gmail.com>
References: <20121029181737.GB16841@vaio.jimpryor.net>
	<201210301738.57593.vkrishn4@gmail.com>
	<20121030142314.742ff63f@vostro>
	<201211251425.18336.vkrishn4@gmail.com>
X-Mailer: Claws Mail 3.9.0 (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 Sun, 25 Nov 2012 14:25:18 +0530 "V.Krishn" <vkrishn4@gmail.com>
wrote:

> > 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.
> 
> Any further thought on - foo-1.2.3-r2.1-my3 ?

Would probably be ok. Though how to distinguish with "-mine" and
"-yours"? Or would the idea be just to have "-myN"?

In this case, could we just not say that "-r<N>" is reserved for Alpine,
and you can do "-r<N>.<myN>".

> > 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.
> 
> I was wanting to release few experimental packages.
> The @ method seems to be more useful in identiying one repository
> from another. What I would like is a effective means to identify
> custom packages from another.

Packages rarely come alone. You would always have special dependencies,
or single source package split to multiple ones in case of those new
feature things (single packages rarely have that kind of
configurability).

It would be better to have them in a reporistory, instead of installing
2-10 package from commandline by hand. I would try to have the
repository creation to be simpler, and encourage using that.

> eg. foo-1.2.3-r2.1-my3 seems to solve this.

That is only one part of the problem. Even if you had identical package
version, apk would distinguish between different builds - it operates
with package identity (shasum) and not the version strings. This is why
'apk cache' adds some digits from the identity to the filename it
caches locally.
 
> > 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.
> 
> Using @ method could possibly be an issue in an automated upgrade
> system.

Adding a specifically build file from command line is also an issue
with automated upgrade system. It is tricky problem in both cases.
 
> > 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.
> 
> What happens in an event the packages get corrupted and packager
> rebuilds personal repo without incrementing _rN?

If looking at just build-data everyone would see that as an update.

Technically correct thing is to take the packages and all it's
dependencies latest commit stamps, and choose the greatest of those and
mark it as the 'preference data'. But that's lot of extra work for very
little.

It'd be simple to just store the 'build date' and use it then figure
out the latest package to install.

- Timo


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