I''ve uploaded Beta 7.
Please note that there is a significant change in this version; the
''shorewall'' package has been renamed
''shorewall-common''.
So the packages included are:
shorewall-common
shorewall-shell
shorewall-perl
shorewall-lite
Users having the current ''shorewall'' RPM installed must
upgrade/install both
shorewall-common and shorewall-shell; e.g.,
rpm -Uvh shorewall-shell-4.0.0-0Beta7.noarch.rpm \
shorewall-common-4.0.0-0Beta7.noarch.rpm
or
rpm -Uvh shorewall-shell-4.0.0-0Beta7.noarch.rpm \
shorewall-perl-4.0.0-0Beta7.noarch.rpm
shorewall-common-4.0.0-0Beta7.noarch.rpm
Note that you *must* include the ''shorewall-shell'' package
even if you
intend to use only shorewall-perl. Once the upgrade is completed, you can
rpm -e shorewall-shell
if you don''t need the old shell compiler.
Failure to include shorewall-shell will result in many messages of the type:
file /etc/shorewall/shorewall.conf from install of
shorewall-common-4.0.0-0Beta7 conflicts with file from package shorewall-3.4.4-1
file /sbin/shorewall from install of shorewall-common-4.0.0-0Beta7 conflicts
with file from package shorewall-3.4.4-1
When installing RPMs from scratch, install shorewall-shell and/or
shorewall-perl together with shorewall-common. If you don''t intend to
use
shorewall-shell, you need not install it.
Users having the current ''shorewall'' package installed via the
tarball can
simply install shorewall-common (and one or both of the compilers). If you
don''t have either shorewall-shell or shorewall-perl currently
installed, you
must install one or both before installing shorewall-common. In no case do
you need to uninstall shorewall.
-Tom
--
Tom Eastep \ Nothing is foolproof to a sufficiently talented fool
Shoreline, \ http://shorewall.net
Washington USA \ teastep@shorewall.net
PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
-------------------------------------------------------------------------
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/
--- Tom Eastep <teastep@shorewall.net> wrote:> the > ''shorewall'' package has been renamed > ''shorewall-common''. > > So the packages included are: > > shorewall-common > shorewall-shell > shorewall-perl > shorewall-liteCan shorewall-perl 4 be used only through shorewall-common 4 (no previous 3.4 shorewalls)? ____________________________________________________________________________________ Get the Yahoo! toolbar and be alerted to new email wherever you''re surfing. http://new.toolbar.yahoo.com/toolbar/features/mail/index.php ------------------------------------------------------------------------- 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/
--- Tom Eastep <teastep@shorewall.net> wrote:> ''shorewall'' package has been renamed > ''shorewall-common''....> In no case do you need to uninstall shorewall.So shorewall < 4.0 and shorewall-common can coexist? If I have shorewall-3.4.3 and want to upgrade to 4.0 then would I need to install shorewall-common-4 and the shorewall-{compilers} ? So my system would have: shorewall-3.4.3 shorewall-common-4.0.0 shorewall-shell-4.0.0 shorewall-perl-4.0.0 Is that correct or would shorewall-3.4.3 have to be uninstalled? Somehow, I found that the naming continuity before Beta 7 was more convenient. Is there an advantage or necessity to introduce shorewall-common? ____________________________________________________________________________________ Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!''s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 ------------------------------------------------------------------------- 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/
Vieri Di Paola wrote:> --- Tom Eastep <teastep@shorewall.net> wrote: > >> the >> ''shorewall'' package has been renamed >> ''shorewall-common''. >> >> So the packages included are: >> >> shorewall-common >> shorewall-shell >> shorewall-perl >> shorewall-lite > > Can shorewall-perl 4 be used only through > shorewall-common 4 (no previous 3.4 shorewalls)?Beginning with RC1, shorewall-perl will require shorewall-common (or at least the RPM will). -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- 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/
Vieri Di Paola wrote:> --- Tom Eastep <teastep@shorewall.net> wrote: > >> ''shorewall'' package has been renamed >> ''shorewall-common''. > ... >> In no case do you need to uninstall shorewall.Did you read the above sentence?> > So shorewall < 4.0 and shorewall-common can coexist?No.> > If I have shorewall-3.4.3 and want to upgrade to 4.0 > then would I need to install shorewall-common-4 and > the shorewall-{compilers} ?Yes> > So my system would have: > shorewall-3.4.3It would *not* have 3.4.3 installed. shorewall-common + shorewall-shell provide exactly the same thing as Shorewall 3.4.4.> shorewall-common-4.0.0 > shorewall-shell-4.0.0 > shorewall-perl-4.0.0 > > Is that correct or would shorewall-3.4.3 have to be > uninstalled?See above.> > Somehow, I found that the naming continuity before > Beta 7 was more convenient. > Is there an advantage or necessity to introduce > shorewall-common?Beginning with Shorewall-4, there is no single package that provide ''shorewall''; you install one or both of the Shorewall compilers (shorewall-shell and/or shorewall-perl). Either compiler requires a set of common files (shorewall-common). Calling any of those three packages ''shorewall'' doesn''t really work, especially when you consider distribution upgrade of RPM-based distros like Fedora or Foobar. The way that we have set up the RPMs now is that both shorewall-shell and shorewall-perl have "Provides: shorewall = ..." and shorewall-shell "Obsoletes: shorewall <4.0.0-Beta6". So an upgrade of a system with shorewall-3.x.x installed will automatically install shorewall-common and shorewall-shell. I don''t want to continue the situation where all users have to install the shell-based compiler whether they want it or not. Going forward, I would prefer that new users install shorewall-perl + shorewall-common. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- 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/
Hopefully the following (from the RC1 release notes) will help clarify.
-Tom
Migration Considerations:
1) Beginning with Shorewall 4.0.0, there is no single
''shorewall''
package. Rather there are two compiler packages (shorewall-shell
and shorewall-perl) and a set of base files (shorewall-common)
required by either compiler package.
Although the names of the packages are changing, you can upgrade
without having to uninstall/reinstall.
To repeat: YOU DO NOT NEED TO UNINSTALL ANY EXISTING PACKAGE.
If you attempt to upgrade using the shorewall-common RPM, you get
this result:
gateway:~ # rpm -Uvh shorewall-common-4.0.0.noarch.rpm
error: Failed dependencies:
shorewall_compiler is needed by shorewall-common-4.0.0-1.noarch
gateway:~ #
You must either:
rpm -Uvh shorewall-shell-4.0.0.noarch.rpm \
shorewall-common-4.0.0.noarch.rpm
or
rpm -Uvh shorewall-shell-4.0.0.noarch.rpm \
shorewall-perl-4.0.0.noarch.rpm \
shorewall-common-4.0.0.noarch.rpm
If you don''t want shorewall-shell, use the second command then
rpm -e shorewall-shell
If you are upgrading using the tarball, you must install
shorewall-shell and/or shorewall-perl before you upgrade
using shorewall-common. Otherwise, the install.sh script fails with:
ERROR: No Shorewall compiler is installed
The shorewall-shell and shorewall-perl packages are installed from
the tarball in the expected way; untar the package, and run the
install.sh script.
Example 1: You have ''shorewall'' installed and you want to
continue
to use the shorewall-shell compiler.
tar -jxf shorewall-common-4.0.0.tar.bz2
tar -jxf shorewall-shell-4.0.0.tar.bz2
cd shorewall-shell-4.0.0
./install.sh
cd ../shorewall-common-4.0.0
./install.sh
shorewall check
shorewall restart
Example 2: You have shorewall 3.4.4 and shorewall-perl 4.0.0-Beta7
installed and you want to upgrade to 4.0. You do not need the
shell-based compiler.
tar -jxf shorewall-common-4.0.0.tar.bz2
tar -jxf shorewall-perl-4.0.0.tar.bz2
cd shorewall-perl-4.0.0
./install.sh
cd ../shorewall-common-4.0.0
./install.sh
shorewall check
shorewall restart
--
Tom Eastep \ Nothing is foolproof to a sufficiently talented fool
Shoreline, \ http://shorewall.net
Washington USA \ teastep@shorewall.net
PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
-------------------------------------------------------------------------
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/
--- Tom Eastep <teastep@shorewall.net> wrote:> Hopefully the following (from the RC1 release notes) > will help clarify.Thank you. ____________________________________________________________________________________ Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=list&sid=396545469 ------------------------------------------------------------------------- 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/
Tom If the host file contains: p3 br0:+sjs p3 br0:+ the following iptables rules are generated: -A br0_fwd -m set --set sjs src -m policy --dir in --pol none -j p3_frwd -A br0_fwd -m set --set src -m policy --dir in --pol none -j p3_frwd My kernel does not contain ipset support therefore this just a visual inspection of the generated iptables rules. I assume the second iptables rule would fail, as it does not contain a set name. Steven. ------------------------------------------------------------------------- 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/
Steven Jan Springl wrote:> Tom > > If the host file contains: > > p3 br0:+sjs > p3 br0:+ > > the following iptables rules are generated: > > -A br0_fwd -m set --set sjs src -m policy --dir in --pol none -j p3_frwd > -A br0_fwd -m set --set src -m policy --dir in --pol none -j p3_frwd > > > My kernel does not contain ipset support therefore this just a visual > inspection of the generated iptables rules. > > I assume the second iptables rule would fail, as it does not contain a set > name.r6738 does a better job of editing host file entries. Thanks, -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- 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/
--- Tom Eastep <teastep@shorewall.net> wrote:> So the packages included are: > > shorewall-common > shorewall-shell > shorewall-perl > shorewall-liteDo you think that future Shorewall releases will always be as a "bouquet" of X packages (currently 4) and all having the same version number? ie. will shorewall x.x.x always include shorewall{-common,-shell,-perl,-lite,-etc...}-x.x.x My doubt is whether there''s a chance (I''d rather hope not) that eg. shorewall-common-4.6.2 is released but, say, shorewall-shell-4.6.2 is not because one can keep using, say, shorewall-shell-4.6.0. 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? As a side question, would the mailing list support reports of users using shorewall-{subpackage} with different version numbers (mainly referring to shorewall-common, -shell and -perl)? I hope I explained myself correctly. ____________________________________________________________________________________ Get the Yahoo! toolbar and be alerted to new email wherever you''re surfing. http://new.toolbar.yahoo.com/toolbar/features/mail/index.php ------------------------------------------------------------------------- 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/
Vieri Di Paola wrote:> --- Tom Eastep <teastep@shorewall.net> wrote: > >> So the packages included are: >> >> shorewall-common >> shorewall-shell >> shorewall-perl >> shorewall-lite > > Do you think that future Shorewall releases will > always be as a "bouquet" of X packages (currently 4) > and all having the same version number? > ie. > will shorewall x.x.x > always include > shorewall{-common,-shell,-perl,-lite,-etc...}-x.x.xThat is an excellent question. It is one that I''ve been asking myself.> > My doubt is whether there''s a chance (I''d rather hope > not) that eg. shorewall-common-4.6.2 is released but, > say, shorewall-shell-4.6.2 is not because one can keep > using, say, shorewall-shell-4.6.0.So you are in favor of releasing all packages with each Shorewall release?> > 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.> > As a side question, would the mailing list support > reports of users using shorewall-{subpackage} with > different version numbers (mainly referring to > shorewall-common, -shell and -perl)?The two compiler packages are dependent on shorewall-common. So the real issue is whether the compiler being used is compatible with the version of shorewall-common installed. Because of the way that Shorewall shell library versioning works, the compilers require a minimum library version in order for the compiled script to run. That dependency is currently enforced when the script is run. In principle, we could support combinations where the installed shorewall-common was "sufficiently new", even if it wasn''t the latest one. We would probably want to enforce that at compile time. Such version dependencies are easy to express using a package manager like rpm or dkpg. They are not so easy with the simple-minded install scripts included with the Shorewall tarballs because there is a chicken-egg problem: a) shorewall-common requires at least one of the compilers. b) each compiler requires shorewall-common of at least a particular version. 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. Any one else have an opinion about this issue? -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- 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/
--- Tom Eastep <teastep@shorewall.net> wrote:> So you are in favor of releasing all packages with > each Shorewall release?At first I would say so (for simplicity) but then again it really doesn''t matter just as long as I know that different versions can be released and are intercompatible.> 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.That''s what I am considering since I''m proposing shorewall ebuilds for the Gentoo portage packaging system. The way ebuilds can be scripted is different if we know that the shorewall-* versions will always have to be the same (in this case only a single shorewall ebuild would be necessary with just a parameter to pull in a specific compiler). However, if shorewall-* versions will differ and be interoperable then separate ebuilds are more appropriate. I guess I''ll consider the "separate ebuild" route just to be on the safe side. ____________________________________________________________________________________ Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz ------------------------------------------------------------------------- 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/
--- Tom Eastep <teastep@shorewall.net> wrote:> a) shorewall-common requires at least one of the > compilers. > b) each compiler requires shorewall-common of at > least a > particular version. > > 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.Maybe the simplest solution would be that shorewall-common be a function library which does not *require* a compiler but of course is almost useless on its own (unless someone might want to link to it from another program). On the other hand, installing "shorewall" would mean installing either shorewall-shell or shorewall-perl or both. The latter packages would however require shorewall-common. That''s just a thought but I don''t know shorewall''s coding details so I guess you would have already done it this way if it were possible at this point in time. ____________________________________________________________________________________ Sick sense of humor? Visit Yahoo! TV''s Comedy with an Edge to see what''s on, when. http://tv.yahoo.com/collections/222 ------------------------------------------------------------------------- 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/
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/
Tom After applying r6750, I get the following error when issuing a "shorewall restart": ERROR: Unable to open /usr/share/shorewall-perl//lib.base: No such file or directory Steven. ------------------------------------------------------------------------- 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/
Steven Jan Springl wrote:> Tom > > After applying r6750, I get the following error when issuing a > "shorewall restart": > > ERROR: Unable to open /usr/share/shorewall-perl//lib.base: No such file or > directoryYou''ll have to copy /usr/share/shorewall/lib.base to /usr/share/shorewall-perl/ -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- 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/
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 \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- 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/