cvs commit: ports/sysutils/pkg_install-devel Makefile distinfo

[Jacques A. Vidrine]

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 at celabo.org / jvidrine at verio.net / nectar at 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...