Sender: =?UTF-8?Q?Timo_Ter=C3=A4s?= <timo.teras@gmail.com>
Date: Mon, 5 Nov 2012 08:15:44 +0200
From: Timo Teras <timo.teras@iki.fi>
To: Dubiousjim <lists+alpine-devel@jimpryor.net>
Cc: alpine-devel@lists.alpinelinux.org
Subject: Re: [alpine-devel] Questions about apk CMD -U
Message-ID: <20121105081544.3f2158cd@vostro>
In-Reply-To: <20121103103845.GA5057@vaio.jimpryor.net>
References: <201210301850.23343.vkrishn4@gmail.com>
	<20121103103845.GA5057@vaio.jimpryor.net>
Precedence: list
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Sat, 3 Nov 2012 06:38:45 -0400 Dubiousjim
<lists+alpine-devel@jimpryor.net> wrote:

> > If everything looks identical - package version, dependencies, etc.
> > Then in practice apk prefers the repository listed first. In case of
> > *.list files, it is currently the physical order in which those
> > files are read. And that can be hard to predict.
> 
> For reference, is /etc/apk/repositories read before (that is, has
> precedence over) repos listed in all *.list files?

Yes, the 'repositories' file is read first and the primary source. In
it ordering is honored somewhat precisely.

> Each of the -my0 and -r0.1 options looks fine to me.
> (I used an analogue of the latter when I was using Arch, though there
> was no official support for it.) Neither gives a way to have custom
> packages ordered BEFORE the r0 for a given version---a need I did
> regularly encounter. But that's not a big deal. What I find a more
> compelling argument is that we should ideally have a single
> recommended method for specifying custom packages, and the @pinned
> mechanism is already in place, and moreover looks more robust and
> flexible.
> 
> I haven't experimented with it yet. If I have foo-1.2.3-r1 installed
> from @myrepo, and foo-1.2.4-r0 comes out on another repo in my list,
> will I at least get an indication that that is there and is being
> skipped? If so, then the pinning mechanism sounds ideal. If not, can
> we talk about adding such notifications, if even in an opt-in way?
> I'm not sure if there are any tricky design issues.

Pinning is strong for the specified package, but weak for dependencies.
So e.g. if you have "bar" and it's dependency "libfoo". And you do
 "apk add bar@mine"

The package 'bar' is always installed from 'mine' if it's there and
installable - regardless if there's newer or older version in some
other repository.

'libfoo' will be installed preferably from the regular repositories,
but if the dependencies are not satisfiable from those, the repository
'mine' is also looked at.

To get notifications of updates:
 - "apk version", displayes the greatest version from the same
   repository tag as the package is currently installed from
 - "apk version -a" displays the greatest version from any known
   repository; so this you can use always to see latest version
   regardless of any pinnings

> > 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).
> 
> I don't mean to weigh in yea or nay about this. But I understand the
> temptation. Epochs are a pain.
> 
> > 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.
> 
> Can each of these be followed by arbitrary text, up to the next '-'?
> Or by /[0-9a-f]*/?

No text or alphabet. Such a suffix is to be followed by an optional
number /[0-9]/ and/or another suffix or alpine package revision.

-Timo


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---