Date: Sat, 3 Nov 2012 06:38:45 -0400
From: Dubiousjim <lists+alpine-devel@jimpryor.net>
To: alpine-devel@lists.alpinelinux.org
Subject: Re: [alpine-devel] Questions about apk CMD -U
Message-ID: <20121103103845.GA5057@vaio.jimpryor.net>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201210301850.23343.vkrishn4@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)


I've been out of commission due to hurricane. Thanks for these answers.

On Tue, Oct 30, 2012 at 08:06:26AM +0200, Timo Teras wrote:
> > If one does have multiple repositories listed in one's
> > /etc/apk/repositories or /etc/apk/repository.d/*.list files, and
> > several of those repos contain foo-1.23-r0.apk, but the package
> > binaries differ, is there any system to which repository will be used?
> 
> Yes - but it is not trivial and depends on the action executed.
> 
> 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?

> If you want to make sure you use always your custom package - add your
> own repository with @ownrepo tag, and use "apk add mypackage@ownrepo"
> to add them. The repository pinning overrides even version matching
> and upgrades - if necessari it will downgrade packages to make it work.
> 
> Alternatively you should modify the version. If the -rN level does not
> matter. Then you could add _p1 suffix before it - e.g. foo-1.2.3_p1-r0.
> Though, there are few packages that use the _pN suffix on their main
> versions (you can still suffix with second _pN too).
> 
> 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?

> ...

> The problem with version numbers is that we need a way to identify
> which is greater and which is lesser in unambiguous way.
> 
> If the source of the package is important, then the repository pinning
> mechanism is more suitable.

> ...

> 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.

This makes sense.

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.

> 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]*/?

-- 
Dubiousjim
dubiousjim@gmail.com


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---