Sender: =?UTF-8?Q?Timo_Ter=C3=A4s?= <timo.teras@gmail.com>
Date: Mon, 5 Nov 2012 13:47:32 +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: <20121105134732.554d3527@vostro>
In-Reply-To: <20121105101955.GA2343@vaio.jimpryor.net>
References: <201210301850.23343.vkrishn4@gmail.com>
	<20121103103845.GA5057@vaio.jimpryor.net>
	<20121105081544.3f2158cd@vostro>
	<20121105101955.GA2343@vaio.jimpryor.net>
Precedence: list
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Mon, 5 Nov 2012 05:19:55 -0500 Dubiousjim
<lists+alpine-devel@jimpryor.net> wrote:

> Thanks for those answers Timo.
> 
> > 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.
> 
> I don't understand what is special here about the handling of libfoo.
> Doesn't the "@mine"-labeled repository also count among the
> repositories checked for _any_ package?

No.

> So if my repository list has:
> 
> http://site.org/main1
> @mine http://site.org/mine
> http://site.org/main2
> 
> And main1 has the packages foo-1.2.3-r0.apk and libfoo-1.2.3-r0.apk
> And mine has the packages foo-1.2.3-r0.apk and libfoo-1.2.3-r0.apk and
> libbar-1.2.3-r0.apk
> And main2 has the package libbar-1.2.3-r0.apk
> And libfoo (but not libbar) is a dependency of foo.
> 
> Then:
>     "apk add foo" will install foo and libfoo from main1

Correct.

>     "apk add foo@mine" will install foo from mine and libfoo from
> main1

Correct.

>     "apk add libbar" will install libbar from mine, won't it?
> because that comes before main2 in the repository list?

No. If repository has a tag name attached it to, it's not used by
default. You are perfectly free to specify the same repository with and
without a tag, though.

> But if main2 had libbar-1.2.3-r1.apk, then "apk add libbar" would
> install from main2. (In that case "apk add mine@libbar" would still
> install from mine.)

Yes.
 
> If libbar was also a dependency of foo, and mine and main2 had the
> same version of libbar, then "apk add foo@mine" will install foo from
> mine, libfoo from main1, and libbar from mine. Since mine comes
> before main2 in the repository list. Right?
> 
> If the behavior I just described *is* what is implemented, then I'm
> not clear on what's the cash value of saying that there's "weak
> pinning" for dependencies. It doesn't look like dependencies are
> treated any different than *explicitly-requested packages with no
> "@mine" suffix*.
> 
> So perhaps the actual behavior is different than what I just
> described?

Slightly different as explained.

The idea is that you can have
v2.4 as main repository
edge as tagged repository

and doing "apk add foo@edge" would not upgrade all of the system
libraries unless necessary due to dependencies.

> > 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
> 
> Ok, then to see what's pinned but may need to be updated, one should
> do something like this after running "apk upgrade -U"?
> 
>     apk version -a -l'<>?' `apk info` | egrep -v '^\.makedepends-'

Or just plain "apk version -a". By default it shows all packages that
can be upgraded (-l '<').

> Is there any easy way to determine what repository a package was
> installed from, so that---say, if one hasn't just run "apk upgrade
> -U"---one can report just the ones currently installed from mine?

Apk version includes the active pinning in the output, so:
 apk version -l'<>=' | egrep "@testing$"

should be ok currently.

Though, we should probably implement 'apk policy' that should be
somewhat similar to 'apt-get policy'.

> > > > 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.
> 
> So no _git21d3919 or _git20121009. Just _git, _git1, and so on?

Yes, no letters or dots. Long numbers are ok though, so _git20121009 is
ok if there's no dot.

This is the current behaviour, but I'm open to suggestions too.

- Timo


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---