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

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

The following reply was made to PR pkg/41087; it has been noted by GNATS.

From: David Holland <dholland-pbugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: pkg-manager%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, 
pkgsrc-bugs%netbsd.org@localhost,
        Aleksey Cheusov <vle%gmx.net@localhost>
Subject: Re: pkg/41087 (OS_VERSION should be removed from PKGPATH)
Date: Mon, 15 Feb 2010 20:31:30 +0000

 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