On Tue, 30 Oct 2012 17:38:57 +0530 "V.Krishn" <vkrishn4_at_gmail.com>
> 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:
> foo-1.2.3_my2-r2.1 <- latest
> foo-1.2.3_my3-r3.1 <- latest
> foo-1.2.3-r4 <- latest
> 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?
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>"
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).
Received on Tue Oct 30 2012 - 14:23:14 UTC