snort ?

[Matthias Saou]

Enrico Scholz wrote :

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

Hmmm... I'm actually never sure which one of /etc/init.d and
/etc/rc.d/init.d is supposed to be the correct one for RH/FC, but I think
it's the latter. I don't see how mixing them could cause "huge problems"
since there's a symlink from one to the other currently, and we're far from
being able to simply nuke it and expect things to still work. Also, I don't
see any mention of init.d nor rc.d in the current FHS (2.3) over at
http://www.pathname.com/fhs/pub/fhs-2.3.html :-(

I'm really not against using a macro for the init scripts in the first
place, on the contrary, but using one with such a weird name, that no one
has even been able to explain to me, is simply something I prefer avoiding
for now.

I'd really love to get any information as to _why_ it's called _initrddir
(such a confusing choice IMHO).

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

Understood. Seems sane and useful, will make that change.

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

What do you mean? I see two options with 2 packages each :
- Have snort, w/ postgresl-libs dep, and snort-mysql and being able to
switch from one to the other with alternatives (or have it be automatic, as
if snort-mysql is installed, it makes sense to use that one).
- Have snort, plain build, and snort-sql with both backends, and again have
alternatives switch between both.

Where to you see any package rebuilding to get a feature here? Maybe I
wasn't clear enough in my previous message, sorry.
As for the oracle backend, it will require a rebuild anyway, so I don't see
it as a problem to just leave it in the main package.

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.25 0.31 0.52