snort ?

[Enrico Scholz]

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

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

Ok... assume a package A which has

| %files
| /etc/init.d/A

for whatever reasons. Now, install this package on an empty system
(e.g. in a '--root' chroot installation). When there are other
flaws (e.g. missing 'Requires(pre): chkconfig|/etc/init.d|...'),
this package might be installed before the /etc/init.d symlink is
created. This will create it as a directory, and the subsequent
installation of 'chkconfig' or 'initscripts' (which would make it a
symlink) can not fix it.

So you will create two init.d directories with a distinct set of
initscripts.


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

mmh... I could swear that FHS specified /etc/init.d as the location for
initscripts. But LSB does it:

| An init.d file is installed in /etc/init.d (which may be a symlink to
| another location).
  [http://www.linuxbase.org/spec//booksets/LSB-Core-generic/LSB-Core-generic/initsrcinstrm.html]


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

Sorry, I can not help here.  But RH6.2 (rpm-4.0.2-6x) has this macro
already.


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

Ok, I assume that there are three classes of people:

* such ones, which want snort without database support (a really minimal
  solution; perhaps usefully in firewalls)
* such ones, which want postgresl support
* such ones, which want mysql support

I do not think that somebody needs both database backends.

Your first option (where I could live with), would discriminate MySQL
users somehow but has good technical reasons (the 50MB perl deps). But
when you create the infrastructure for multiple subpackages, why not
create all three packages (plain, psql, mysql)?


> Where to you see any package rebuilding to get a feature here?

E.g. when you decide to package option 2 (plain + mysql/psql), I can not
use the prebuild packages from Fedora Extras but would have to rebuild
it manually (I need psql but do not want MySQL + deps on the machine).


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

Yes, that's clear. With packages outside of Fedora, you are on your own.



Enrioc