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: Tue, 8 Dec 2009 03:58:52 +0000

 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