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

[Aleksey Cheusov <cheusov%tut.by@localhost>]

> 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.