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>
index | next in thread | previous in thread | raw e-mail
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...home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040417152242.GA5543>