snort ?

[Daniel Wittenberg]

With the regular snort RPM's we used /etc/init.d mainly because of
standards and made it easier for portability, since most other RPM-based
distros we saw were using /etc/init.d

We also did split the packages are purpose because of what is mentioned
here, the 3 classes of people wanting 3 different builds, and when snort
is on firewalls and sometimes critical area, people tend not to want it
to be bloated with more code than it has to.  

Just FYI on why we did things certain ways in case it helps.

Dan

On Fri, 2005-02-04 at 17:51 +0100, Enrico Scholz wrote:
> 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
> 
> --
> fedora-extras-list mailing list
> fedora-extras-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-extras-list