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)

> 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