Date: Mon, 5 Nov 2012 05:19:55 -0500
From: Dubiousjim <lists+alpine-devel@jimpryor.net>
To: alpine-devel@lists.alpinelinux.org
Subject: Re: [alpine-devel] Questions about apk CMD -U
Message-ID: <20121105101955.GA2343@vaio.jimpryor.net>
References: <201210301850.23343.vkrishn4@gmail.com>
 <20121103103845.GA5057@vaio.jimpryor.net>
 <20121105081544.3f2158cd@vostro>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20121105081544.3f2158cd@vostro>
User-Agent: Mutt/1.5.21 (2010-09-15)

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?

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
    "apk add foo@mine" will install foo from mine and libfoo from main1
    "apk add libbar" will install libbar from mine, won't it? because
that comes before main2 in the repository list?

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.)

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?

> 
> 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-'

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?


> > > 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?

-- 
Dubiousjim
dubiousjim@gmail.com
https://github.com/dubiousjim


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---