Andrew Suffield wrote: > 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.
In Shorewall, the interface to lib.base and lib.cli are quite stable while the interface to lib.config tends to be more fluid. Although much of that fluidity recently has been a result of Shorewall-perl. > > 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. The lib.base library has had versioning since the days when it was called /usr/share/shorewall/functions. The other libraries have not. Note that lib.cli is only used by /sbin/shorewall and /sbin/shorewall-lite and is packaged along with both Shorewall-common and Shorewall-lite. > > 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). See below -- I think we'll take a different approach on a package basis. > >> 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. Exactly. In the context of the above discussion, the cases of Shorewall-shell and Shorewall-perl are quite different. a) Shorewall-shell and Shorewall-common have traditionally been one product so their code is more tightly intertwined. Shorewall-perl was designed as an add-on. b) Shorewall-shell is written in Bourne shell so it directly uses the libraries in Shorewall-common. c) Shorewall-perl is written in Perl and only the generated script uses a library (lib.base) in Shorewall-common. d) Shorewall-shell is already slow and is used in environments where disk space is at a premium. d) Shorewall-perl is fast and has a large disk footprint already because of its dependency on Perl. So I think that the solution will be different in the two cases: a) Shorewall-shell's version will remain more or less lock-stepped with Shorewall-common. I've inserted run-time checks to ensure that both lib.base and lib.config are the same ones that Shorewall-shell is expecting. The existing mechanism of versioning between the generated script and lib.base will continue to be used. b) Shorewall-perl will have its own copy of lib.base which it will copy into the generated script (Shell's version of static linking). In that respect, all scripts generated by Shorewall-perl will be like export scripts in that they will be completely self-contained shell programs. The end result will be that Shorewall-shell and Shorewall-common will have much tighter version dependencies than will Shorewall-perl. And in all cases, those dependencies will need to be carefully documented and enforced. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ [EMAIL PROTECTED] PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- 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
