snort ?

[Enrico Scholz]

thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) writes:

>> * %{_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
> :-/

Mixing the FHS compliant /etc/init.d and the RH style /etc/rc.d/init.d
would cause huge problems (e.g. two independent directories with
initscripts). Therefore, I prefer to use the %_initrddir macro across
all packages.


>> * 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.

Correct. These rules can be compared with an antivirus database and
should be updated regularly. The release cycles of snort are much too
long for this.


> So, a "snort-rules" package with mutual requirements between it and
> "snort" is what you'd expect? In general,

Add a 'Requires: rules(snort)' in the main package, and a 'Provides:
rules(snort)' in your rules package.


>> * 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),

Yes, postgresql-libs are ok. But as you said: MySQL requires perl which
needs 50MB.


> 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 :-)

This would save only one subpackage... I do not know if we want a Gentoo
style system where everybody has to configure and build the packages
with the appropriate switches himself.




Enrico