On Mon, Jul 02, 2007 at 07:09:59AM -0700, Tom Eastep wrote: > > Until now, the various shorewall packages have always > > been released together with the same version number. > > Is that going to stay the same in the fairly far > > future? > > The advantage of releasing the packages separately on > their own schedule is that we end up with fewer total > packages to support. The downside is the never-ending > confusion that users will have about what works with > what.
The real disadvantage is the inverse of this advantage: if you release the pacakges separately and are insufficiently careful about it, you have a combinatorial explosion of version combinations to support, leaving you worse off than when you started. If there are currently three supported versions of shorewall-common, and four of each compiler, then there are (3*4) + (3*4) == 24 possible installed combinations, each of which may display unique bugs (as opposed to 4 combinations if the packages were released together with strict dependencies). It is necessary to use techniques that reduce the number of combinations which display *significant* differences. As a general rule, for all library-dependency issues of this form in any language, release the packages together until the library interface is mostly stable - any sooner and the problem is unmanageable complex. After that, try to batch together changes to the library interface, to reduce the number of combinations. A change is considered to be an "interface" change if it's externally visible and replaces previously working behaviour with different behaviour. For example, support for a new kernel or new iptables feature doesn't replace working behaviour, so it's safe, while a change in the return value of one of the library functions may cause unforseen bugs, so it's unsafe. You may want to use a strict version check based on this - keep an "interface version" and increment it in every release which makes an interface change like this, and require all the packages to have *matching* interface versions, not just "more recent than X" versions. This is a parallel of soversions in unix shared libraries. In theory it will eliminate all version-related bugs, but it requires considerable care and attention to use correctly (you have to consider the impact of every change, and decide whether to put it in the next release or queue it for a later one along with an interface version bump). Some people do this right (glibc), and some do it spectacularly badly (libpng). > Which package do we install first? As things stand right now, > we install the compiler first and the shorewall-common > install script insists that there be a compiler. That means > that if the shorewall-common is too old for the installed > compiler(s), we won't know about it until the first time > that a compiler is run. The best you can easily do is to detect some common errors and reject them. I suggest that if the install script insists there be a compiler, you can have it ask that compiler what versions it will support, and leave it at that. People who want 'correct' behaviour here should use one of the existing package managers, this is why they exist. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Shorewall-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-devel
