X-Original-To: alpine-devel@lists.alpinelinux.org
Delivered-To: alpine-devel@mail.alpinelinux.org
Received: from mail-da0-f54.google.com (mail-da0-f54.google.com [209.85.210.54])
	(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
	(No client certificate requested)
	by mail.alpinelinux.org (Postfix) with ESMTPS id DF624DC00F3
	for <alpine-devel@lists.alpinelinux.org>; Wed, 28 Nov 2012 15:03:01 +0000 (UTC)
Received: by mail-da0-f54.google.com with SMTP id n2so4063510dad.13
        for <alpine-devel@lists.alpinelinux.org>; Wed, 28 Nov 2012 07:03:00 -0800 (PST)
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=KEO0QS1R/JCVlFBx1wcLKzehSaQMUxc4O7yX4ErPcL4=;
        b=KoefhJTR46rDibw+MpfDboSYRcHS8EWD/U1Qrbp+E2+oOpFs1WWDNjTWHZ7pXgsjff
         Nu2tKvzb52p+HqsyVAPdFy8Sv2pVKGxGrk71NyNHCKUs32vrD5fue8LwlHE+F+Rtu8OH
         LXpSlaWnbYOf4nzSRIr4U+6wUPfqYvekllBnDhnIpzYLSQY5YHQW32xITsRNL6siDkFw
         0mENKZXj3qCHQiM98pPyzCRNA98pzdzfDQElMm5hPO+pe36iPWaL3PV0v1YAmmwhRerX
         Eo7BsgZKhdat4+48B/T0sHuBYcCu32jt2pnKepIQQRRguRhfzeWlLH9nxvy1YCKBAz0y
         9XIA==
Received: by 10.68.244.135 with SMTP id xg7mr58810194pbc.87.1354114980543;
        Wed, 28 Nov 2012 07:03:00 -0800 (PST)
Received: from microknoppix.localnet ([117.227.234.207])
        by mx.google.com with ESMTPS id sz6sm12565447pbc.52.2012.11.28.07.02.24
        (version=TLSv1/SSLv3 cipher=OTHER);
        Wed, 28 Nov 2012 07:02:58 -0800 (PST)
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: Wed, 28 Nov 2012 20:27:53 +0530
User-Agent: KMail/1.13.7 (Linux/3.3.7-64; KDE/4.7.4; x86_64; ; )
References: <20121029181737.GB16841@vaio.jimpryor.net> <201211251425.18336.vkrishn4@gmail.com> <20121128115317.333ba6a8@vostro>
In-Reply-To: <20121128115317.333ba6a8@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: <201211282027.53247.vkrishn4@gmail.com>

On Wednesday, November 28, 2012 03:23:17 PM you wrote:
> 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 ?

The additional notations assumes that alpine orig packages would not be using 
them, but are meant only for custom packagers.

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

1. Eg. here both have same weight 
   (note the absense of orig package from alpine)
   foo-1.2.3-r2.1-abc3 <- latest (first come first serve)
   foo-1.2.3-r2.1-xyz3

2.   
   foo-1.2.3-r2  
   foo-1.2.3-r2.1-abc3 <- latest (first come first serve)
   foo-1.2.3-r2.1-xyz3

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

Yes, this could work. Only that any logic comparision with base package would 
be very meaningful.

Possibly could not do things like:
   foo-1.2.3-r2 
   foo-1.2.3-r2.1-abc4
   foo-1.2.3-r2.2-abc3 <- latest

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

Yes.
I was wanting to release few experimental packages. meaning one package would 
be having slight modifications but would work alongwith orig package 
dependencies. It is also possible that experimental packages have few features 
enabled in build scripts.

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

So how is the distinguishing established?

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

-- 
Regards.
V.Krishn


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