major changes suggestions: features versions and SYSTEM package

Ok. Here is my final suggestion, please comment and discuss.

FEATURE VERSIONNING
===================

Features versions SHOULD NOT be mandatory anymore. Each feature will now 
REQUIRE a serial number *or* a snapshot date. A feature version COULD BE 
supplied as an advisory number and to ease maintanance. One could 
compare the serial number to our PORTEPOCH.

This will dramatically ease maintenance and feature comparaison. We will 
avoid the nightmare of the current version scheme [1]  which is 
ridiculously complex and is surely worse than having just an serial 
number (integer) as version number.

([1]: old pkg version scheme: [0-9]+(\.[0-9]+)*(_[0-9]+)*(,[0-9]+)*, eg. 
1.2.4_6,2 , what a mess.)

In a worse case scenario, version numbers could be used in a scheme 
closed as they are now. That is:

- the printed form of the feature CAN NOT be a basis for feature 
comparaison. We have an API, let's use it.
- RCS-like version number syntax: 0|([1-9]+)(0|([0-9]+))* (e.g. 0.1 or 
1.2.1.3.1, but *not* 1.2_9,1)
- version numbers DO NOT have precedence over the serial number. Eg. 1.1 
serial 12 > 1.2 serial 0. At worst, a port wishing to rely only on the 
version to differenciate the features could bump the snapshot date (or 
the serial number, but that's more ackward) when a new version comes in. 
This is a bit too error-prone so hooks could be put in place in the 
ports collection to detect and warn about case where the maintainer 
tries to do something odd such as 1.1 serial 12 -> 1.2 serial 0, and 
automatically correct the situation (1.1 serial 12 -> 1.2 serial 12). 
maintainers wishing to use *only* the version number could then simply 
set the serial number to 0 and let the version numbers be compared.
- snapshot date vs serial number conflicts. As before, serial numbers 
and snapshot dates can be both specified. Only before we didn't have any 
explicit way of dealing with this. It is simply a matter of which data 
is in priority. I would be tempted to suggest that the serial number 
overrides the snapshot date, but I'm not sure this is really the most 
intuitive thing to do. I think it would be good to have really the 
PORTEPOCH "hammer" (ie. all powerful overriding) reflected in the serial 
number.

That gives us an almost backward compatible feature spec and gives us 
enough flexibility to deal with most cases.

SYSTEM PACAKGE SPECIFICATION
============================

SYSTEM will provide the following features (e.g.):

Name           Version     Serial     Snapshot Date
FreeBSD        4.5         *          **
i386           0           0          0
i686           0           ***        0
SYSTEM         0.2.2****   0          0

* __FreeBSD__
** branch snapshots
*** the serial number could be a bitfield representing CPU options, but 
that sounds like a very bad idea.
**** this is the libh version.

A few comments... The SYSTEM package CAN NOT, of course, provide the 
"libh" feature since it is not libh itself.  libh, if installed, will 
provide this feature, since not all systems will require libh to be 
installed. But by synching itself with libh's version, the SYSTEM 
feature will give an idea of its capabilities to consumers.

This scheme merges the OSVERSION and OSNAME features, and is a lot 
cleaner, I think.

I will start implementing this shortly if no opposition arises. Roadmap:

1- sweep the documentation and convert the current scheme to the new one 
using in part this email
2- comment the code and place strategic #warnings where things should be 
changed
3- full implementation of package versions and SYSTEM package
4- roll a new libh release, we'll be long due. :)

2 and 3 don't exclude modifying the API.

I'll put this on the web shortly.

A.



To Unsubscribe: send mail to [email protected]
with "unsubscribe freebsd-libh" in the body of the message