* Jolan Luff <[EMAIL PROTECTED]> [051102 20:13]:
> On Thu, Nov 03, 2005 at 12:04:15AM +0100, Marc Espie wrote:
> > In order to get you more confused, we've got more bright ideas about
> > version numbering...
> >
> > Right now, we mostly use the `vendor' number scheme, and we add a simple
> > p* suffix to denote what's going on with the OpenBSD port.
> >
> > As we've noticed, some times, vendor version numbers go backwards, or we
> > don't plan enough in advance, and it gets confusing.
> >
> > For instance, kde uses a scheme like 3.4.3, 3.4.92, 3.5, which is fine.
> >
> > gcc is going from gcc-3.3.20050920 to gcc-3.3.6 (release).
> >
> > The idea is to add some v* suffix each time the numbering scheme changes.
> >
> > So, if pkg_add can compare version numbers on its one, we don't need any
> > suffix for that.
> >
> > If it can't, then we need to bump v*. As expected, we start with an empty
> > v* suffix...
> >
> > So, with that scheme, gcc would go from 3.3.20050920 to 3.3.6v0
> >
> > Some comments:
> > - we still need the p* stuff to denote OpenBSD specific changes.
> > - v* versions mean we can go backwards. If we find a security issue,
> > and we have to go back from foo-2.0 to foo-1.9, then we just bump v* so
> > that it becomes foo-1.9v0, which is higher than foo-2.0...
> >
> > The main objection you can have is that this is too complicated, but so
> > far, we haven't been able to find any hole in that scheme...
> >
> > Opinions ?
>
> I was actually just thinking about this. I am in the process of
> updating multimedia/libdvdnav from 0.1.10 to a cvs snap versioned
> 20051102. I was wondering how the pkg update stuff would handle that if
> 0.1.11 came out.
>
> Your solution makes sense but there are still some things that are weird
> to me with how things are done now:
>
> 1) x11/xglobe's Makefile has:
>
> DISTNAME= xglobe-0.5p2
> PKGNAME= ${DISTNAME:S/p2/p10/}
>
> Seems sort of silly to have to strip vendor versioning in order to preserve
> our own notation.
>
> 2) The pkg tools make lots of assumptions based upon the package name
> and yet the pkg tools don't care if invalid package names are being
> used. It would be nice if pkg_create detected invalid package names and
> bombed out.
>
> I'll admit that neither of these are particularly important issues, but
> since we're talking about changes in this area I thought it would be a
> good time to mention them.
>
> I think ideally it would be nice to have something like:
>
> REVISION=epoch_seconds_when_package_was_last_changed (any sort of
> monotonically increasing value would do)
>
> and embed this identifier in the package as a true version
> identifier and completely do away with package names, OpenBSD patch
> level, v0, etc. and just use the vendor versioning mechanism strictly as
> a name but look at REVISION for the real "is this newer or not"
> information. This would require adding such an identifier to every
> package and subpackage which could be a lot of work.
>
> Again, I think your idea makes sense and is relatively cheap to
> implement. But it would be cool to solve this sort of stuff
> once-and-for-all rather than increase the dependencies and complexity of
> parsing the embedded version information that is contained in the
> package name.
>
I was thinking something similar. DNS sequence numbers were the first
thing coming to my mind. I just hadn't thought it out much at all.
Personally, I like the idea of "monotonically increasing values" but
that's the database purist in me peeking out.
The value of my input is proportional to the number of ports I maintain.
Meaning, I bow to the porting masters and their experience.
Jim
