snort ?

Matthias Saou thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net
Thu Feb 3 22:24:52 UTC 2005


Enrico Scholz wrote :

> > Feedback very welcome of course!
> 
> ok...
> 
> * is there a 'make' missing in %build?

Indeed, d'oh! :-)

> * rules should be installed with the '-p' switch to keep timestamps
>   (useful e.g. for automatic updates)

Right, can always be useful.

> * %{_sysconfdir}/rc.d/init.d should be written as %_initrddir

That one, I'm not sure. No one has ever been able to confirm or dis-confirm
to me if this confusing name was normal or actually a typo. %_initddir or
%_rcinitdir I would have understood... but %_initrddir!? IMHO, having
"initrd" is really weird, that's why I tend ot avoid that macro altogether
:-/

> * Requires(...): are missing for the %scriptlets

Yup, thanks for noticing.

> * I would put the rules into a separate subpackage to allow easier
>   updates

I guess you mean "custom" or "local" updates, right? Indeed, it could be
interesting to override the defaults. So, a "snort-rules" package with
mutual requirements between it and "snort" is what you'd expect? In
general, I'd probably be opposed to such a split, but in this case, as this
is a package that is clearly targeted at sysadmins and advanced users, it
does make sense.

> * As I like and use minimal systems I would prefer -mysql, -postgresql
>   subpackages which use 'alternatives' to set a link to
>   /usr/sbin/snortd. So, unneeded dependencies will be prevented

I understand, but that will add quite a bit of complexity to the package...
the postgresql-libs are only 360kB and don't have any special deps, so the
extra 420kB created by an additional snort binary makes it a loosing
situation, definitely not "worth the trouble" from my POV. OTOH, mysql
pulls in 5MB+ and some deps (perl modules and eventually others on minimal
systems), so maybe just only enabling PostgreSQL support by default could
be done, as it is the "preferred" RH/FC detabase anyway, and leave the
MySQL optional with the rpmbuild switch?

Or... just have alternatives choose between the plain version and another
"db" version which has both databases supported? Hey, I actually think this
last idea isn't that bad :-)

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.760_FC3
Load : 0.33 0.24 0.18




More information about the fedora-extras-list mailing list