Mail archive
alpine-devel

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

From: V.Krishn <vkrishn4_at_gmail.com>
Date: Tue, 30 Oct 2012 18:50:23 +0530

On Tuesday, October 30, 2012 05:53:14 PM you wrote:
> On Tue, 30 Oct 2012 17:38:57 +0530 "V.Krishn" <vkrishn4_at_gmail.com>
>
> wrote:
> > On Tuesday, October 30, 2012 05:24:27 PM you wrote:
> > > On Tue, 30 Oct 2012 13:25:03 +0530 "V.Krishn" <vkrishn4_at_gmail.com>
> > >
> > > wrote:
> > > > > 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?
> > > >
> > > > 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.
> >
> > 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.
>
> So how does this differ from -r1.1 thing?

 foo-1.2.3_my3-r2.1

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

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

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

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

Its position in name is just suggestive.

 foo-1.2.3-r2.1-my3 perhaps?

-- 
Regards.
V.Krishn
> 
> 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
---
Unsubscribe:  alpine-devel+unsubscribe_at_lists.alpinelinux.org
Help:         alpine-devel+help_at_lists.alpinelinux.org
---
Received on Tue Oct 30 2012 - 18:50:23 UTC