snort ?

[Michael Schwendt]

On Wed, 02 Feb 2005 22:19:55 -0600, Daniel Wittenberg wrote:

> 
> > 2.) An update request stalled in QA because it was a huge and complete
> > rewrite which had many issues, and when built, it didn't result in binary
> > packages which would upgrade the existing fedora.us packages. Interest in
> > fixing it and getting an update published didn't seem to exist.
> 
> This is the first I have heard of this.

Desinterest is the only suitable interpretation for inactivity since 2003.

> > While the old update tried to cover SuSE Linux and other distributions
> > with lots of conditional spec sections, that newest one fiddles with
> > macros to switch between Fedora and Caos. Lots of other conditionals
> > increase the spec file's size to 2.4 times the size of Dag Wieers'
> > spec. 
> 
> Just curious, but what does the size of the .spec file mean?  I have
> seen some pretty big, complicated .specs coming out of RH for packages,
> so little confused about why this seems to be so important to you.

It isn't important.

It's just a comparison as a result of reviewing a src.rpm which didn't
even build

  https://bugzilla.fedora.us/attachment.cgi?id=383&action=view

and which apparently was unfinished work-in-progress with no clear word on
what version was considered the final release candidate.

Hence when work starts on seeking for the cause of a failed build, lots of
unclean/sloppy packaging is found in addition to clear defects, and
general cleanup is suggested (such as replacing absolute paths with rpm
macros and making short-circuit installs possible). So it can be
concentrated on making the important parts of a spec file work and
increase the likelihood that it will build successfully in the build
environment.

I don't argue about how elaborate spec files (think XFree86/xorg-x11) can
be, when they "just work" or when the package maintainer knows his stuff
and manages to build the desired binaries from them.

However, in a large spec which fails, lots of mistakes and pitfalls are
buried beneath many unnecessary things, which decrease readability and
increase maintenance requirements.

> > And it should at least build with defaults and not require lots of
> > manual --with/without switches.
> 
> I agree with this one.
> 
> > I'm not aware of any new package submission policies for Fedora Extras
> > yet. These will likely come in the future.
> > 
> > I don't know whether we apply any first-come first-served rule when
> > somebody submits a package. ;)
> > 
> > It has been suggested that maybe Dag Wieers, who also maintains Snort
> > packages, might want to maintain them in Fedora Extras, too.
> > 
> > If multiple people are interested in creating and maintaining Snort
> > packages in Fedora Extras, it would be great if they discussed and
> > finished a candidate source rpm. Starting there, it could be imported into
> > CVS and built for testing.
> 
> That's fine with me too obviously, it just seems odd that you wouldn't
> want the people maintaining the official RPMs to maintain these too with
> little to no extra effort.

Nobody said that.  Apparently, the rpms are not ready.  And what effort
will be necessary to maintain them remains to be seen. You don't know what
road of development the packages will take in Fedora CVS.  IMO, there's
nothing like a Fedora packaging prerogative for people who provide rpms
for upstream projects. It would be beneficial if package maintainers have
good contact with upstream developers. But it could be that the Fedora
community disagrees with the rpms provided there and would want the
packaging to be different.

Concerning the bits which build for cAos Linux, I would consider it
wrong to accept them and would not feel good about it. Once included,
other packagers would want to include spec sections which handle the
peculiarities of e.g. Mandrake Linux or SuSE Linux, respectively.
Unsupported areas.

-- 
Fedora Core release 3 (Heidelberg) - Linux 2.6.10-1.760_FC3
loadavg: 0.10 0.55 0.36