pkgsrc-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

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

From: Aleksey Cheusov <>
To: David Holland <>
,  Aleksey Cheusov 
Subject: Re: pkg/41087 (OS_VERSION should be removed from PKGPATH)
Date: Tue, 08 Dec 2009 08:52:18 +0200

 > 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.
 IIRC TNF currently supports two versions of NetBSD 4.x and 5.x.  Right?
 At home I'm running NetBSD-5.0 where lsof- is installed,
 that is lsof built for NetBSD-4.0.
 It works *perfectly*.
 So, original problem doesn't exist even on NetBSD.
 >  : #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. 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).
 > 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.
 >  : #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.
 No. One of the system I'm running have kernel
 version which is incompatible with pkgsrc dewey convension and is larger
 and messier than 2.01.01alpha59pre2nb1.
 That is OS version just breaks the package.
 > 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.
 Best regards, Aleksey Cheusov.

Home | Main Index | Thread Index | Old Index