Date: Thu, 16 Oct 2014 16:44:44 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 194401] bsd.port.mk's OSVERSION change interferes with option WITHOUT_TOOLCHAIN in src.conf Message-ID: <bug-194401-8-XKazaWAA2e@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-194401-8@https.bugs.freebsd.org/bugzilla/> References: <bug-194401-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D194401 --- Comment #3 from Harald Schmalzbauer <bugzilla.freebsd@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 in= to any unknown project. Downloading source doesn't implicate the intention to compile it =E2=80=93 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-o= nly (temporary) ports tree because it's the fastest way (I'm ware of) to determ= ine 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 hos= t, like what complete port set is installed, corresponding db/ports/* options etc.) and roll out a package repository CD on that build host, which afterw= ard 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: >=20 > OSVERSION!=3Dsysctl -n kern.osreldate >=20 > 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 poss= ible with 'sysctl -n kern.osreldate' Thanks, -Harry --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-194401-8-XKazaWAA2e>