Re: SNORT not adding entries to snort/portscan ???

[Dale Amon <amon@vnl.com>]

On Sat, Nov 30, 2002 at 01:56:53PM +0100, Adrian Phillips wrote:
> >>>>> "Dale" == Dale Amon <amon@vnl.com> writes:
>     Dale> I've a general issue along those lines. There are often
>     Dale> tools I'd like to install but most packages specify >= a
>     Dale> version of libc6 even when the package would basically run
>     Dale> with any libc that ever existed.
> 
> I would have thought a reasonable number of packages can be upgraded
> by grabbing the source, patching using the Debian diff and
> dpkg-buildpackage'ing. I've done this on a small number of packages
> without problems. Some manualy fixing of the diff maybe necessary
> obviously if there are bug fix patches included that aren't required
> for the newer version.
> 
> I was under the impression that if people wished to have newer
> "stable" versions then it is up to individuals to handle this
> themselves. It is not something that the Debian project can be
> expected to maintain.

Perhaps I did not state this clearly enough. The majority of cases
I run across are caused by an entirely unnecessary dependancy to
a version of libc6 which isn't in any way required for the package
in question. Yes, one can fix this manually. Every time, for every
package. Which naturally means you do it once or twice and then
say "oh forget it" and wait a year or whatever until the next stable
upgrade.

Package Dependencies on lib versions (or any other entity for that
matter)  really are several entirely different things:

	* the API changed and my application will fail with any
	  lib version prior to this one because it relies on
	  the changes.

	* bug fixes went into this lib version without which my
	  app will crash.

	* bug fixes went into this version which I specifically
	  want/prefer for my application, but it won't crash
	  on the older one.

	* I just like to use the latest set of lib version digits
	  for no particular reason.

I suspect the majority of package version dependencies fall into
the last category.

If this was dealt with, there would be a much higher level of
interoperability between packages in various dists. Still a 
caveat emptor, but far, far easier to deal with.