Jens Rehsack <rehsack%googlemail.com@localhost> writes: > Hi, > > I had a question and didn't get response from Andrew, so I hoped someone > here could give me some feedback. > > I checked out sysutils/lsof and seen, that the OS version number is attached > to the version number of the package. I understood the intension - e.g. for > Linux distributions it's a difference for lsof which kernel is used. But > could it solved using a version number? I further understand, that it's not > recommended to run an lsof build on NetBSD-4.0.1 on NetBSD-5, but does a > version number prevent that? > > Maybe it could be rated as a warning for the packager, but no user will ever > see. What options does the packager can choose? He can compile the package > for every targeted OS version, rename the binaries containing the version > numbers and use a script choosing the right binary. Keeping that up to date > is hell. > > My suggestion is, skip adding the version number of the OS the the package > version. I think your approach makes sense. In general, programs built under a version of an operating system may only work well under that version. Next, in general NetBSD is good at binary compat, so most things work ok under newer versions, except of course kmem grovelers. But, even with regular programs, binary packages depend on shared libraries and those change in major number. So one really should have packages that match the OS. The real problem here is that there are hidden dependencies on the base OS. Since pkg_rr is my hammer, I'd like to have these expressed and have the OS upgrade process mark things dirty. Looking at the lsof Makefile, I see OSVERSION_SPECIFIC=yes. That should stay, because it does actually record an OS dependency via a build def. We just need a tool to set unsafe_depends on all such packages, to be run after updating if the new kernel version differs from the recorded one.
Attachment:
pgpKTZFZ6Z7fL.pgp
Description: PGP signature