[Bug 194401] bsd.port.mk's OSVERSION change interferes with option WITHOUT_TOOLCHAIN in src.conf

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194401

--- Comment #3 from Harald Schmalzbauer <bugzilla.freebsd at omnilan.de> ---
(In reply to Brooks Davis from comment #2)
> Sorry, missed your examples in the first message.  I apologize for not
> reading carefully.  The first two cases seem like the sort of thing we'd
> like to note support as they could be harmful to the project.  It really
> don't make sense to update a port if you can't build it.

The 'make makesum' example is from a very special case! We do automated
'distfile' updates for local (inofficial) ports with a script running on a
jail-host without toolchain.

The 'make fetch' example is often useful if you want to get a quick look into
any unknown project. Downloading source doesn't implicate the intention to
compile it – but it could be done in a very convenient way with the help of
'make fetch'.

Checking for updates without compiling them (portmaster -ai e.g.) absolutely
makes sense, also on machines which can't even compile anything themself!
I frequently do this on remote machines without toolchains, but with read-only
(temporary) ports tree because it's the fastest way (I'm ware of) to determine
what updates _would_ be available.
If there's something relevant for upgrading revealed, I go to the build host
(which has knwoledge of detailed project info regarding the destination host,
like what complete port set is installed, corresponding db/ports/* options
etc.) and roll out a package repository CD on that build host, which afterward
gets mounted on the destination machine and pkg upgrade will do the rest.

(Using FreeBSDs pkg repositroy is not an option for almost all of my setups,
since virtually every port was compiled with non-standard options defined!)

> The error message suggests a perfectly functional workaround.  Why is that
> not acceptable?  Just add:
> 
> OSVERSION!=sysctl -n kern.osreldate
> 
> to your make.conf or put in your environment.

For the same reason it was changed in bsd.ports.mk. It's very often wrong.
Doesn't matter for the tasks described here, but I think there's a better
solution - unconditionally shipping param.h. Like described, regardless of the
WITHOUT_TOOLCHAIN option, there's always a populated /usr/include directory
tree, so adding the 11kB "param.h" shouldn't hurt in any way, but it could be
used as a reliable source of correct version information, which si not possible
with 'sysctl -n kern.osreldate'

Thanks,

-Harry

-- 
You are receiving this mail because:
You are the assignee for the bug.