> It's based on the approach that I tried to explain to you the last time
> the topic came up. Glad you like it.
>
As I already said - congratulations!
>> [ -n "$DESTDIR" ] || DESTDIR="$PREFIX"
>> #! so, DESTDIR is always set, no matter what
>> #! [...]
>>
> It is only set if you set it explicitly or you set PREFIX explicitly; If
> you specify neither, then DESTDIR is undefined.
>
> There are two scenarios supported by install.sh:
>
[etc]
Your logic is completely fraud, I am afraid. What does specifying the
destination directory has to do with the type of distribution I have or
will use shorewall for? I'll tell you what - absolutely nothing, nada!
One is completely separate from the other.
Let me repeat that again - what destination directory I choose to use
has absolutely nothing whatsoever to do with the type of distro I have/I
am building shorewall for.
If your install.sh script is trying to determine what distro I am using
(again, an entirely fraud premise as, as you rightly pointed out below,
I could be building shorewall on one distro for another, in which case
currently your install.sh will fall apart) should be entirely separate
from the DESTDIR logic - completely different and separate issues. As it
currently stands, that is not the case - both are lumped together,
creating an unholy mess!
> Since what you have written seems to focus on ridiculing the code rather
> than discussing your requirements that the scripts don't meet, I'm
> having to read between the lines.
Nope, I am just pointing out the error in your ways - nothing more,
nothing less.
> But it sounds like you are asking for
> the ability to install into a directory while applying distribution
> settings?
>
Nope! About 18 months ago I have asked to get the right script included
in my shorewall build (by the right script, I mean the proper init.d
script - a version of that file usually sits in the main shorewall
source directory) instead of getting the rather crappy version of it,
which is of no use to me whatsoever.
> I have a requirement to be able to install into a directory on one
> distribution while applying settings for another distribution (I build
> Shorewall exclusively on Debian or OS X).
>
> So I can envision something like:
>
> cd shorewall-4.5.0
> DISTDIR-/tmp/foo FEDORA=Yes ./install.sh
>
So, let me get this straight - in order to get the twisted logic in
install.sh to work, I have to specify DESTDIR, <DISTRO>=yes as well as
SYSTEMD=yes when running install.sh? You'd better run and tell all the
shorewall distro maintainers out there, because I am not sure all of
them are aware of this.
Besides (and I am judging this from Fedora's perspective as this is the
distro I employ on all my machines - that and EL), hard-coding the
initdir in your install.sh is going to cause all SRPMs distributed with
Fedora to fail as there isn't such directory in the buildroot called
/etc/init.d - that directory is properly set via environment variable
during the install.sh call and is duly ignored by that script.
So, even if I *do* set FEDORA=yes, even if I do set SYSTEMD=yes, even
then the build is going to fail - miserably so, because the init.d
directory is hard-coded in install.sh
> I can change the install scripts so that the detected settings will be
> applied within the directory as well.
>
IMO, if you are going to do "target-distro sniffing", well, do it
properly! As you rightly pointed out, I could be building on one distro
for another and as all your packages are noarch-designated the
install.sh "target-distro sniffing" will currently fail, miserably.
Rely on either the proper target distro variables
(FEDORA/DEBIAN/ARCHLINUX etc) being set in advance (they should always
take precedence of what install.sh determines to be "sane" values) or
include "target-distro sniffing" as a default option if nothing has been
set, in which case make it clear in the build log what is the result of
that sniffing, and what install.sh has determined as target distro,
directories, files (including sysv or systemd) etc that will be used, so
that errors are easily corrected and not like as it is now, I had to
spend about an hour debugging a bloody shell script to see what the hell
is going on!
Regardless of whether the target distro option has been set up initially
or "sniffed out" by install.sh, the application of the distro-specific
logic should be completely separate from whether or not the DESTDIR has
being set - the one has absolutely nothing whatsoever to do with the
other and should be treated as such by install.sh. That was the error in
install.sh which caused me to get that crappy init.d script installed -
it has been going on for year and a half!
>> if [ -z "$DESTDIR" ]; then
>> #!
>> #! ... and neither will this branch, thus SYSTEMD NEVER gets set!
>> #!
>> if [ -f /lib/systemd/system ]; then
>> SYSTEMD=Yes
>> fi
>> elif [ -n "$SYSTEMD" ]; then
>> mkdir -p ${DESTDIR}/lib/systemd/system
>> fi
>>
> Although you can:
>
> cd shorewall-4.5.0
> SYSTEMD=Yes ./install.sh
>
As if!
>> #! [...]
>>
>> #
>> # Install the Firewall Script
>> #
>> if [ -n "$DEBIAN" ]; then
>> #!
>> #! Never happening!
>> #!
>>
> I beg your pardon, but it happens every time I install or update a
> Shorewall product on any of my systems.
>
Yeah, when you don't specify neither the prefix, nor the destdir and
only if you use debian. If you use fedora instead, or specify either
prefix or destdir - it fails, miserably, but you already know that,
don't you?
>> #!
>> #! BUG number 2: if any of "${DESTDIR}" or "${DEST}" have spaces in them
>> you are royally screwed!
>> #!
>> fi
>>
> I frankly don't care.
>
I know you do!
>> The above is valid for all install.sh files, *except* shorewall-init -
>> there is a special case there - in addition to the above, we have this
>> little gem:
>>
>> elif [ -n "$FEDORA" ]; then
>> install_file init.debian.sh ${DESTDIR}/etc/init.d/shorewall-init 0544
>> #!
>> #! Wrong on so many levels!
>> #!
>>
> Indeed -- corrected.
>
Thank you! I hope you take into account the initdir setting and do not
hard-code this stuff, because building srpm will definitely fail with
"/etc/init.d" being hard-coded.
> That is the defect that Simon reported and that will be corrected in
> 4.5.0.1.
>
I wasn't aware of what Simon had posted until I read it on the ML, don't
be so precious!
>> 2. masq
>>
>> [...]
>>
>> 4. Last, but not least, there are some WHITELIES in the
>> shorewall-blrules man page - I thought you ought to know and correct
>> this so that nothing but the plain truth is only shown on that page.
>>
> Okay, I'll work on those as time permits.
>
I hope it won't take you 18 months to fix these. Let me know if you need
a hand.
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
