Re: pkg/41087 (OS_VERSION should be removed from PKGPATH)

[David Holland <dholland-pbugs%netbsd.org@localhost>]

On Mon, Dec 07, 2009 at 09:10:08PM +0000, Aleksey Cheusov wrote:
 >> As lsof is a kmem-groveler, it *is* dependent on exact kernel version, you
 >> *should* recompile it after changing kernels, and having the kernel version
 >> in the package name is a convenient way to make sure this happens.
 >  
 > There are several points against OS version in PKGNAME discussed in this
 > thread.  By closing this PR you silently ignored all of them.

On the contrary, I think I covered them all. This is what I see:

 : #1 There are definitely more than two packages that heavily depend
 : on a particular kernel/OS version.

Sure. If there are other kmem grovelers or LKMs floating around they
should be given the same treatment for the same reason.

 : #2 This "depends" may vary from system to system.

Fair enough. If you are *sure* that lsof is completely independent of
anything kernel-ABI related on Linux, then it's easy enough to disable
the behavior on Linux. But remember that Linux has had quite a few
incompatible changes of /proc format, and not all programs adjust at
runtime. Does lsof? I dunno.

For that matter, if someone wants to take the trouble to track down
what needs to be done to make lsof use only maintained ABIs on NetBSD
or any other platform it's easy enough to adjust the package
accordingly.

In the meantime it should stay dependent on kernel version.

 : #3 Package versions become a mess.

It's simple and tidy compared to e.g. cdrtools 2.01.01alpha59pre2nb1
that showed up last spring. I don't think this is a convincing
argument.

There's also the argument that it's untidy from a semantic
perspective, because the kernel version is not properly part of the
package version. This is true. On the other hand, it solves a specific
and real problem. I don't think patching every package version
handling program to know about and add special-case checking for the
kernel version is a workable alternative.

What does come to mind is adding a dummy package whose version
*is* the kernel version and having lsof depend on it. This would also
solve the problem and be less messy.

-- 
David A. Holland
dholland%netbsd.org@localhost