Bug 194401 - [src/include/Makefile] [patch] bsd.port.mk's OSVERSION change interferes with option WITHOUT_TOOLCHAIN in src.conf
Summary: [src/include/Makefile] [patch] bsd.port.mk's OSVERSION change interferes with...
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: misc (show other bugs)
Version: 10.0-STABLE
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-16 10:45 UTC by Harald Schmalzbauer
Modified: 2018-04-10 01:01 UTC (History)
2 users (show)

See Also:


Attachments
Install /usr/include/sys/param.h with WITHOUT_TOOLCHAIN set (695 bytes, patch)
2014-10-16 10:45 UTC, Harald Schmalzbauer
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Harald Schmalzbauer 2014-10-16 10:45:23 UTC
Created attachment 148369 [details]
Install /usr/include/sys/param.h with WITHOUT_TOOLCHAIN set

In ports/Mk/bsd.ports.mk the following cahnge was made:
-OSVERSION!=	${SYSCTL} -n kern.osreldate
+.error Unable to determine OS version.  Either define OSVERSION, install /usr/include/sys/param.h or define SRC_BASE.

On systems which were installed with "WITHOUT_TOOLCHAIN=true" in src.conf, there is no 'param.h'.
Since BSD.include.dist will always be populated by mtree at installworld stage, regardless the WITHOUT_TOOLCHAIN option, I'd like to see param.h beeing present an all systems, also regardless of WITHOUT_TOOLCHAIN.

The attached patch incorporates this.
It's useful for using the ports-tree as information source, when someone might want to 'make fetch' or 'make makesum' (for automated updates of own ports) or 'make -V'...
Comment 1 Brooks Davis freebsd_committer 2014-10-16 15:35:31 UTC
How is the ports collection remotely useful on a system without a toolchain?  I guess "make index" might work, but nothing will build so what's the point?
Comment 2 Brooks Davis freebsd_committer 2014-10-16 16:06:49 UTC
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 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.
Comment 3 Harald Schmalzbauer 2014-10-16 16:44:44 UTC
(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