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>