[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pkg/41087 (OS_VERSION should be removed from PKGPATH)
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-184.108.40.206.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
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
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
Main Index |
Thread Index |