Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 17 Apr 2004 10:22:42 -0500
From:      "Jacques A. Vidrine" <nectar@FreeBSD.org>
To:        Oliver Eikemeier <eikemeier@fillmore-labs.com>
Cc:        ports-committers@FreeBSD.org
Subject:   Re: cvs commit: ports/sysutils/pkg_install-devel Makefile distinfo
Message-ID:  <20040417152242.GA5543@madman.celabo.org>
In-Reply-To: <40802354.3030202@fillmore-labs.com>
References:  <200404160124.i3G1OlUd067575@repoman.freebsd.org> <20040416163635.GB49780@madman.celabo.org> <4080151C.1070200@fillmore-labs.com> <20040416173857.GA50670@madman.celabo.org> <20040416174418.GC50670@madman.celabo.org> <40802354.3030202@fillmore-labs.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Apr 16, 2004 at 08:17:56PM +0200, Oliver Eikemeier wrote:
> Jacques A. Vidrine wrote:
> >On Fri, Apr 16, 2004 at 12:38:57PM -0500, Jacques A. Vidrine wrote:
> >
> >>On Fri, Apr 16, 2004 at 07:17:16PM +0200, Oliver Eikemeier wrote:
> >>
> >>>Jacques A. Vidrine wrote:
> >>>
> >>>>On Thu, Apr 15, 2004 at 06:24:47PM -0700, Oliver Eikemeier wrote:
> >>>>
> >>>>>Introduce '*' as the lowest possible version number, so that
> >>>>> >=2.* <3.*
> >>>>>matches all 2.X versions, even alpha.
> >>>>
> >>>>How is this different from  ` >=2.a <3.a ' ?
> >>>
> >>>It matches 2.a.b, does not match 3.a.b2
> >>
> >>*scratches head*   I still don't see a difference.
> >>
> >>  2.a <= 2.a.b < 3.a
> >>  2.a <= 3.a   < 3.a.b2
> >
> >*blink* Oh, wait, I got that wrong.  2.a > 2.a.b and 3.a >
> >3.a.b2.  Except that version names such as `2.a.b' and `3.a.b2' are
> >unacceptable.
>
> See biology/fasta3 for an example. They may be unacceptable for portlint,
> but pkg_install has to be as tolerant as possible, and needs a consistent
> definition of version numbers.

fasta3-33.t08.d4

Yes, it seems this version number is broken with regards to the current
rules.

> >>>and is more similar to >=2.X than >= 2.a is.
> >>
> >>How so?  Maybe you mean to say that 2.a > 2.* ?
> >>I find that rather confusing.
>
> I meant that 2.* is somewhat similar to 'all 2.X versions'. Of course
> you have to be careful to get things right, but at least it is a proper
> definition of 'the lowest possible version number' instead of hoping
> that it would be 2.a.

According to the current rules, there is no version beginning with 2
that comes `before' 2.a.  There's no need to `hope' this is true: that
is what the rules currently say :-)

> There are already lot of entries in VuXML which
> erroneously assume it would be 2.0.

Would you mind pointing them out?  Or perhaps you are making some
erroneous assumptions.  The intervals defined within VuXML are based
upon *actual versions*, not `possible versions'.  So unless there is an
entry such as

   <range><ge>2.0</ge><lt>2.5</lt></range>

where there was a vulnerable package version `2.0.a', there is no
issue.

(NOTE WELL: *package* version, as in *FreeBSD package*, not *vendor*
version.)

> >I think I'm with you now.  `*' is not a version number, but a glob?
>
> Nope, * is a version number that can not be assigned to a port. It is
> guaranteed to be the lowest possible one, and there is a similarity between
>  portname-2.*
> and
>  portname>=2.*
> the first being a glob (matching all 2.X versions, but not 02.1), the second
> a relational comparison (matching all 2.X versions, but 3.2 too) . It may be
> confusing, but in most cases it is easy to do the right thing, and things
> like 2.# or 2.% aren't really better.

Ugh.  Oh well, I think I like the utility of `*' as a more natural way
of expressing `all versions of this release, including alpha', and I
agree other symbols aren't really any better.  So, you mention that
you devised an encoding below.  How do you encode an interval in which
one end includes `*'?  In mine (outlined below), I guess I'd give it
a value prior to `a' e.g. my letter encoding sequence would be based
upon `*abcd...'.

> >>Btw, at least for pkg_install-devel we have 2.pl0 < 2.a.
> >
> >How did that become broken?  What does 2.pl0 even mean?  Do you have
> >an example?  I'm certain that is against our naming conventions.
>
> Nope, refer to the FreeBSD Porter's Handbook, 5.2.4 Package Naming
> Conventions:
> <http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-naming.html#PORTING-PKGNAME>;
>
> Item 4. mentions `pl' as a version number, so it is special (like NetBSD's
> nb),
> and it makes no sense to allow it only as a standalone component.

I think you need to re-read that section, in particular:

   The only exception is the string pl (meaning ``patchlevel''),
   which can be used *only* when there are no major and minor version
   numbers in the software.

2.pl0 is not a valid package version.  The only valid package versions
that include the string `pl' are of the form `plN'.

> >I'm concerned because I have a function that converts a package
> >version into a 128 bit integer, such that if the package version A is
> >greater than package version B, then f(A) > f(B).  If the versioning
> >rules are being changed, I wanna know (and I'd also like to know why).
>
> I have a function that converts a version number into a floating point
> number < 1.0, such that A > B iff f(A) > f(B). I doubt that 128 bits are
> sufficient in every case, but I may be wrong.

You are wrong. :-)  I found that 96 bits is more than enough for
everything in INDEX today.  I used 128 bits just in case.  Since
my representation is actually a sequence of 32 bit integers, this
is easily extended should it become necessary.  If it does become
necessary, though, then I think something else is broken :-)  [1]

Funny that you `doubt that 128 bits are sufficient', yet you claim to
be using floating point.  If you are using `long double's, aren't you
limited to about 64 bits?

> Do you have a reference to a definition of the versioning rules
> besides PR 56961?

You have some nerve :-)  PR 56961 is only your individual
interpretation, not a `definition of the versioning rules' or
`reference' of any type.  The rules are defined by the Porter's
Handbook, and supplemented by *the real* (not your) pkg_install.


I *would* like to see the package versioning rules made more clear and
explicit, and perhaps even see some reform.  However, making up a new
special case for `pl' seems right out.

Has much discussion over PR 56961 taken place anywhere?  I like it as a
starting point.

Cheers,
-- 
Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org

[1] The encoding works something like so.  The version is encoded as
a sequence of variable length bit strings.  Each component of the
version string is converted to a bit string depending upon whether it
is a number or letter:

   000x xxx1                     4-bit number
   001x xxxx xxx1                8-bit number
   010x xxxx xxxx xxxx xxx1      16-bit number
   011x xxxx xxxx xxxx xxxx      32-bit number
        xxxx xxxx xxxx xxx1
   1xxxxx1                       letter (1=a, 2=b, ...)

Those trailing `1' bits are replaced with `0' for our special case
where a letter follows a `.' immediately.

The first bit string in the sequence is derived from PORTEPOCH,
the middle strings from PORTVERSION, and the final string from
PORTREVISION.

To convert our sequence of bit strings into a 128 bit integer, the
strings are concatenated and right-padded with zero bits.

I expected someone to ask ``why is this useful?''   It is useful to
allow tools that don't grok our version numbering scheme to still sort
our version numbers, e.g. sort, awk, SQL, Excel...



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040417152242.GA5543>