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 <cheusov%tut.by@localhost>
To: David Holland <dholland-pbugs%netbsd.org@localhost>
Cc: gnats-bugs%NetBSD.org@localhost,  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, 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-4.78.4.0.1nb5 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 2.6.22.16-vs2.2.0.6ext 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