snort ?

[Michael Schwendt]

On Thu, 03 Feb 2005 12:18:43 -0600, Daniel Wittenberg wrote:

> 
> > Not repeating my previous replies, though. Most important, a default
> > "rpmbuild --rebuild snort-2.3.0-0.fdr.1.src.rpm" creates a single package,
> > no MySQL support, no Postgresql support, and so on. This doesn't look like
> > intended. 
> 
> Still not clear on this, when I rebuild it I get the one RPM with no DB
> support. ?

Unlike the packages offered for download at snort.org, unlike the older
packages in fedora.us, unlike Dag's package. Why only a single package
without db support? Why are all sub-packages disabled by default?

> > and cAos specific sections (commented on that before) and
> > vendor/packager tag mangling, 
> 
> I didn't personally add the cAos build info, and still not sure what's
> wrong with having it there, doesn't hurt anything unless you explicitly
> build for it.  Like having the oracle build info, it's there if you want
> it (and some people have used it, make their life easier), but doesn't
> hurt anything normally.

cAos Linux specific spec sections and an optional Oracle sub-package are
two completely different things. As outlined earlier, if such cAos related
sections made it into a Fedora Extras package, it would open the door for
Mandrake/SuSE/whatever specific spec code as requested by other packagers
who might want to add something like that. And once in CVS you would want
to update those spec sections, too, although they are unrelated. Where to
draw the line? I say we package for Fedora and maybe the various flavours
of Red Hat Linux. If someone really packages for multiple unrelated
distributions, it should not be so much effort to keep multiple spec files
in sync.

> > well as the silly buildroot=/ checks
> > which add no safety (emptying the buildroot anywhere else than at the
> > start of %install makes a poor and confusing spec design).
> 
> Some of this was legacy for broken RPM setups that wouldn't do these
> checks, and were almost always added in response to things getting
> hosed.  I agree that we've come along ways in the last year with RPM
> building that most of this stuff shouldn't happen anymore and can be
> cleaned up.

Several years ago already, and superfluous if buildroot is set at the top
of a spec file. ;)