Re: Version numbering of sysutils/lsof

[Bernd Ernesti <netbsd%lists.veego.de@localhost>]

On Fri, May 01, 2009 at 07:53:24AM -0400, Greg Troxel wrote:
> Jens Rehsack <rehsack%googlemail.com@localhost> writes:
> > Hi,
> >
> > I had a question and didn't get response from Andrew, so I hoped someone
> > here could give me some feedback.
> >
> > I checked out sysutils/lsof and seen, that the OS version number is attached
> > to the version number of the package. I understood the intension - e.g. for
> > Linux distributions it's a difference for lsof which kernel is used. But
> > could it solved using a version number? I further understand, that it's not
> > recommended to run an lsof build on NetBSD-4.0.1 on NetBSD-5, but does a
> > version number prevent that?

It may not prevent that, but it makes it clear if there is a problem
that the binary was build for another kernel version that the currently
running one.

> > Maybe it could be rated as a warning for the packager, but no user will ever
> > see. What options does the packager can choose? He can compile the package
> > for every targeted OS version, rename the binaries containing the version
> > numbers and use a script choosing the right binary. Keeping that up to date
> > is hell.

Is a problem, but that will always be the cause if a program uses a kernel
internal interface.

> > My suggestion is, skip adding the version number of the OS the the package
> > version.
> 
> I think your approach makes sense.  In general, programs built under a
> version of an operating system may only work well under that version.
> Next, in general NetBSD is good at binary compat, so most things work ok
> under newer versions, except of course kmem grovelers.  But, even with
> regular programs, binary packages depend on shared libraries and those
> change in major number.  So one really should have packages that match
> the OS.

The only problem here is that lsof uses a kernel internal interface and it
is not really a good idea to run an old lsof binary which is for an older
kernel.

> The real problem here is that there are hidden dependencies on the base
> OS.  Since pkg_rr is my hammer, I'd like to have these expressed and
> have the OS upgrade process mark things dirty.

I wouldn't call that a hidden dependency, but there are problems to prevent
an installation of a binary package.

> Looking at the lsof Makefile, I see OSVERSION_SPECIFIC=yes.  That should
> stay, because it does actually record an OS dependency via a build def.
> We just need a tool to set unsafe_depends on all such packages, to be
> run after updating if the new kernel version differs from the recorded
> one.

What does this do and how is that related to a leaf package?

Bernd