Subject: [alpine-devel] Questions about apk CMD -U

From: Dubiousjim <[email-masked]>
Date: Mon, 29 Oct 2012 14:17:37 -0400

I'm doing some wiki cleanup, and have come across some issues I don't
know the answer to. Can someone please clarify what is the EXACT effect
of the -U/--update-cache flag for apk in each of the following
circumstances:

1. apk update -U (with an APK package cache enabled? without?)
2. apk add -U  (with an APK package cache enabled? without?)
3. apk upgrade -U (with an APK package cache enabled? without?)

I assume that the -U flag in cases 2 and 3 makes it unnecessary to first
run an "apk update". Is that correct? Is the -U flag in case 1 a no-op?
Does the -U flag ever run an implicit "apk cache download", or anything
of that sort?

If anyone remembers at which earlier points in Alpine history the present behaviors became
available, and what the preceding behavior was, that may also help with
some wiki pages describing how to upgrade from older systems. For
example, at which point could one begin relying on apk to upgrade
apk-tools first, if necessary?

-- 
Dubiousjim
[email-masked]

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---

---

From: Timo Teras <[email-masked]>
Date: Mon, 29 Oct 2012 20:43:43 +0200

On Mon, 29 Oct 2012 14:17:37 -0400 Dubiousjim
<[email-masked]> wrote:

> know the answer to. Can someone please clarify what is the EXACT
> effect of the -U/--update-cache flag for apk in each of the following
> circumstances:
> 
> I assume that the -U flag in cases 2 and 3 makes it unnecessary to
> first run an "apk update". Is that correct? Is the -U flag in case 1
> a no-op? Does the -U flag ever run an implicit "apk cache download",
> or anything of that sort?

the -U flag always does the one and same thing. It executes
 "apk update"
before running the real command.

So "apk update -U" is redundant and -U does there nothing.
 
> If anyone remembers at which earlier points in Alpine history the
> present behaviors became available, and what the preceding behavior
> was, that may also help with some wiki pages describing how to
> upgrade from older systems. For example, at which point could one
> begin relying on apk to upgrade apk-tools first, if necessary?

commit 59d222d - upgrade: perform upgrade of apk-tools first if available
is dated Sat Jan 1 15:48:10 2011 +0200 which is first included in
apk-tools version 2.1.0.

So the feature was first present in Alpine Linux 2.3.0_rc1.

If you are updating the apk-tools wiki page, please describe the package
"pinning" syntax too. This is the "apk add foo@edge" style syntax.

-Timo

---

---

From: Dubiousjim <[email-masked]>
Date: Mon, 29 Oct 2012 15:15:24 -0400

On Mon, Oct 29, 2012 at 08:43:43PM +0200, Timo Teras wrote:
> ...

Thanks Timo, this enabled me to fix some confusing/incorrect statements
in the wiki. (Some but not all introduced by me.)

The "apk add asterisk=1.6.0.21-r0" and "apk add 'asterisk<1.6.1'" syntax
is already described at
http://wiki.alpinelinux.org/wiki/Alpine_Linux_package_management

I'm not familiar with the "apk add foo@edge" syntax. What if my
/etc/apk/repositories file looks like this:

    /var/lib/packages/main
    /var/lib/packages/testing
    http://nl.alpinelinux.org/alpine/edge/main
    http://nl.alpinelinux.org/alpine/edge/testing

I assume that the "... foo@edge" syntax will force whatever foo package
is in one of the last two repositories to be counted as most recent. But
which one? Does it look at both of them? What else is usable in the
"@edge" position of "foo@edge"? I assume "@v2.4" is also usable. What
about "@main" or "@testing"? If you want to point me to the release
notes describing this functionality, or write up a quick explanation,
I'll be glad to format it and merge it into the wiki.

-- 
Dubiousjim
[email-masked]

---

---

From: Timo Teräs <[email-masked]>
Date: Mon, 29 Oct 2012 22:02:18 +0200

----- Original message -----
> > commit 59d222d - upgrade: perform upgrade of apk-tools first if
> > available is dated Sat Jan 1 15:48:10 2011 +0200 which is first
> > included in apk-tools version 2.1.0.
> > 
> > If you are updating the apk-tools wiki page, please describe the
> > package "pinning" syntax too. This is the "apk add foo@edge" style
> > syntax.
> 

The tags need to be defined in repositories file. See:

http://git.alpinelinux.org/cgit/apk-tools/commit/?id=500f8d4a7d7b17871647392e79e4c7a17c210534

This is quite unique feature in apk... to the degree that the pinnings are specified on command line and not in config file like apt. Also the dependency pulling is rather smart - and getting smarter in v2.5.

Few other things to mention might be:
http://git.alpinelinux.org/cgit/apk-tools/commit/?id=77e203bf3224293d8f8e01dd15d6262eed840cf9
http://git.alpinelinux.org/cgit/apk-tools/commit/?id=ba3ee3f86396f05123f732da7c7879c8ed016c9d

These are since alpine v2.4.

-Timo

---

---

From: Dubiousjim <[email-masked]>
Date: Mon, 29 Oct 2012 18:57:47 -0400

> These are since alpine v2.4.

Thanks Timo, I'll add some notes about these to the wiki. Have a look at
it sometime later and see whether it looks right.

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?

Here's why I ask. I'm still in the process of shifting myself into
Alpine. From past experiences with Arch and FreeBSD, I've noticed the
following pattern. I tend to accumulate a bunch of packages which are in
the official repositories, but for which I want to customize the build.
The way I've settled into doing this is to have a personal git branch in my
aports repo. Then when the official APKBUILDs get updated, I'll see the
changes when I try to merge the master branch with my personal branch.

But what version should I give my custom packages? Ideally, I'd want to
be able to insert any number of my own revisions in between the official
foo-1.23-r0 and foo-1.23-r1. I'd also want to be able to insert any
number of my own revisions before the official foo-1.23-r0, if I end up
building that before it appears in the official repositories. If there's
some way to insert my packages into gaps in the existing versioning space,
terrific.

If not, then I'm guessing the best thing to do is to name my custom
package foo-1.23-r0 also. It will be a different binary than the
official foo-1.23-r0. But if I arranged for my local package
repositories to be searched first, then I'd be sure to always get my
home-built packages, unless the official binary gets ahead of me
version-wise. This is why I'm asking which repos in one's
/etc/apk/repo** files have priority over the others.

I'm sure others have come up with schemes to deal with this. I'd welcome
any feedback about what tends to work best.

-- 
Dubiousjim
[email-masked]

---

---

From: Timo Teras <[email-masked]>
Date: Tue, 30 Oct 2012 08:06:26 +0200

On Mon, 29 Oct 2012 18:57:47 -0400 Dubiousjim
<[email-masked]> wrote:

> /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.
 
> following pattern. I tend to accumulate a bunch of packages which are
> in the official repositories, but for which I want to customize the
> build. The way I've settled into doing this is to have a personal git
> branch in my aports repo. Then when the official APKBUILDs get
> updated, I'll see the changes when I try to merge the master branch
> with my personal branch.
> 
> But what version should I give my custom packages? Ideally, I'd want
> to be able to insert any number of my own revisions in between the
> official foo-1.23-r0 and foo-1.23-r1. I'd also want to be able to
> insert any number of my own revisions before the official
> foo-1.23-r0, if I end up building that before it appears in the
> official repositories. If there's some way to insert my packages into
> gaps in the existing versioning space, terrific.
> 
> I'm sure others have come up with schemes to deal with this. I'd
> welcome any feedback about what tends to work best.

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?

- Timo

---

---

From: "V.Krishn" <[email-masked]>
Date: Tue, 30 Oct 2012 13:25:03 +0530

> "customized" builds or similar, like '-r1.1'. Any opinions on this?

How does _pN suffix get applied?
I mean , can it be any _<text>N? 
if not then '-r1.1' may not be very helpful, coz package name should indentify 
the packager in someway.

-- 
Regards.
V.Krishn

---

---

From: Timo Teras <[email-masked]>
Date: Tue, 30 Oct 2012 13:54:27 +0200

> How does _pN suffix get applied?

It is part of the version string. Before -rN, but after the version.
E.g. 1.2.3_p1-r0.

> I mean , can it be any _<text>N? 

No.

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.

> if not then '-r1.1' may not be very helpful, coz package name should
> indentify the packager in someway.

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.

-Timo

---

---

From: "V.Krishn" <[email-masked]>
Date: Tue, 30 Oct 2012 17:38:57 +0530

> which is greater and which is lesser in unambiguous way.

Just a thought:

eg.
 foo-1.2.3-r2
 foo-1.2.3_my2-r2.1 <- latest

eg.
 foo-1.2.3-r2
 foo-1.2.3_my2-r3.1
 foo-1.2.3_my3-r3.1 <- latest

eg.
 foo-1.2.3-r4 <- latest
 foo-1.2.3_my2-r3.1
 foo-1.2.3_my3-r2.1

eg.
 foo-1.2.3_my2-r3.1
 foo-1.2.3_my3-r2.1 <- latest

whole thing should work on assumption that
presence of any suffix should only be considered new if its root foo-
<version>-<rev>N are same or greater.
In absence of root package both suffixN and rN are evaluated.

> mechanism is more suitable.

Yes, I guess, the preferred method.

-- 
Regards.
V.Krishn

---

---

From: Timo Teras <[email-masked]>
Date: Tue, 30 Oct 2012 14:23:14 +0200

On Tue, 30 Oct 2012 17:38:57 +0530 "V.Krishn" <[email-masked]>
wrote:

> > > > "customized" builds or similar, like '-r1.1'. Any opinions on
> > > > this? Or any other ideas?
> > > 
> > 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.
> > 
> > > if not then '-r1.1' may not be very helpful, coz package name
> > > should indentify the packager in someway.
> > 

So how does this differ from -r1.1 thing?

The idea was that Alpine would use -rN (where n does not contain dot)
only. And would leave the customized packages to use "-rN.<MY-VERSION>"
syntax.

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.

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.

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.

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

- Timo

---

---

From: "V.Krishn" <[email-masked]>
Date: Tue, 30 Oct 2012 18:50:23 +0530

foo-1.2.3_my3-r2.1

here 'my' is the packager
Note: predefined suffix _cvs, _svn etc are prefixed to packager 'name'

> only. And would leave the customized packages to use "-rN.<MY-VERSION>"

-rN.<MY-VERSION> , here number after dot would make it easier to know the 
weight as compared to base/orig package.

> before "-rN" confuses as it would be sorted in non-logical order.

Its position in name is just suggestive.

 foo-1.2.3-r2.1-my3 perhaps?

-- 
Regards.
V.Krishn

---

---

From: Dubiousjim <[email-masked]>
Date: Sat, 3 Nov 2012 06:38:45 -0400

I've been out of commission due to hurricane. Thanks for these answers.

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

> is that packages alone do not work - their dependencies must come from

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.

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

> version without any suffix.

Can each of these be followed by arbitrary text, up to the next '-'? Or
by /[0-9a-f]*/?

-- 
Dubiousjim
[email-masked]

---

---

From: Timo Teras <[email-masked]>
Date: Mon, 5 Nov 2012 08:15:44 +0200

On Sat, 3 Nov 2012 06:38:45 -0400 Dubiousjim
<[email-masked]> wrote:

> > *.list files, it is currently the physical order in which those
> > files are read. And that can be hard to predict.
> 

Yes, the 'repositories' file is read first and the primary source. In
it ordering is honored somewhat precisely.

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

---

---

From: Dubiousjim <[email-masked]>
Date: Mon, 5 Nov 2012 05:19:55 -0500

Thanks for those answers Timo.

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

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

> number /[0-9]/ and/or another suffix or alpine package revision.

So no _git21d3919 or _git20121009. Just _git, _git1, and so on?

-- 
Dubiousjim
[email-masked]
https://github.com/dubiousjim

---

---

From: Timo Teras <[email-masked]>
Date: Mon, 5 Nov 2012 13:47:32 +0200

On Mon, 5 Nov 2012 05:19:55 -0500 Dubiousjim
<[email-masked]> wrote:

> > 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"
> > 
> > but if the dependencies are not satisfiable from those, the
> > repository 'mine' is also looked at.
> 
> Doesn't the "@mine"-labeled repository also count among the
> repositories checked for _any_ package?

No.

>     "apk add foo" will install foo and libfoo from main1

Correct.

>     "apk add foo@mine" will install foo from mine and libfoo from

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.

> install from main2. (In that case "apk add mine@libbar" would still

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

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.

> Ok, then to see what's pinned but may need to be updated, one should
> do something like this after running "apk upgrade -U"?
> 

Or just plain "apk version -a". By default it shows all packages that
can be upgraded (-l '<').

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

> > > > 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]*/?
> > 

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

---

---

From: "V.Krishn" <[email-masked]>
Date: Sun, 25 Nov 2012 14:25:18 +0530

> before "-rN" confuses as it would be sorted in non-logical order.

Any further thought on - foo-1.2.3-r2.1-my3 ?

> informative purpose. I would prefer not - and just make people learn

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.

eg. foo-1.2.3-r2.1-my3 seems to solve this.

> is that packages alone do not work - their dependencies must come from

Using @ method could possibly be an issue in an automated upgrade system.

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

-- 
Regards.
V.Krishn

---

---

From: Timo Teras <[email-masked]>
Date: Wed, 28 Nov 2012 11:53:17 +0200

> Any further thought on - foo-1.2.3-r2.1-my3 ?

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

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

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

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.
 
> > In general - it seems we should be going more for "packages come
> > from certain repository" and sort them accordingly, even if it means
> > 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.
> 

Adding a specifically build file from command line is also an issue
with automated upgrade system. It is tricky problem in both cases.
 
> > 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

---

---

From: "V.Krishn" <[email-masked]>
Date: Wed, 28 Nov 2012 20:27:53 +0530

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

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

> 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

> feature things (single packages rarely have that kind of

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.

> 'apk cache' adds some digits from the identity to the filename it

So how is the distinguishing established?

-- 
Regards.
V.Krishn

---