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

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

On Tue, Dec 08, 2009 at 06:55:02AM +0000, Aleksey Cheusov wrote:
 >>  : #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.
 >  
 >  IIRC TNF currently supports two versions of NetBSD 4.x and 5.x.  Right?
 >  At home I'm running NetBSD-5.0 where lsof-4.78.4.0.1nb5 is installed,
 >  that is lsof built for NetBSD-4.0.
 >  It works *perfectly*.

That it works for some tests in some cases (or have you exhaustively
checked it and done coverage analysis? I doubt that) doesn't prove
anything.

Maybe it's no longer a kmem-groveler on NetBSD and uses only stable
interfaces. I don't know; I haven't inspected the sources. Have you?

 >>  : #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.
 >
 >  I didn't read lsof sources and didn't compare kernel headers but I know
 >  exactly that lsof built with 2.6.18 kernel headers works perfectly on
 >  Linux-2.6.26.

Again, that it appears to work is not the same as it really being
version-independent. Linux in particular has a long history of
arbitrary and incompatible changes to file formats in /proc that tools
like lsof rely on.

 >  I'd like to see OS version removed from PKGNAME under
 >  Linux by default. Patching pkgsrc sources is not a good solution
 >  (actually they are already patched).

I don't see that this would be correct. Perhaps we can agree on a
different approach, like the version-number packages I suggested?

 >  > 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.
 >
 >  Package's PKGNAME just cannot contain an information about all
 >  incompatibilities between different kernels of libcs (why not to add a
 >  libc's version to PKGNAME too ;-) ). As OBATA Akio said PKGNAME's
 >  purpose is different.

Then some other mechanism is needed.

 > > 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.
 >
 >  Actually it doesn't. See above. Original problem doesn't exist for
 >  supported versions of NetBSD and doesn't exist on other systems.

Yes, it does. Or at least, you haven't shown that it doesn't.

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