[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 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-220.127.116.11.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
No. One of the system I'm running have 18.104.22.168-vs22.214.171.124ext 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.
Main Index |
Thread Index |