Differences

This shows you the differences between two versions of the page.

--- warnerlosh:usrlocal [2015/10/14 23:05] – WarnerLosh
+++ warnerlosh:usrlocal [2015/10/28 22:33] (current) – WarnerLosh
@@ Line 64: / Line 64: @@
 ==== pkgconf ====
-The pkgconf program already looks in /usr/libdata/pkgconfig and /usr/local/libdata/pkgconfig for data to do its job. This is not consistent with not looking in /usr/local that other tools in the toolchain implement. It is also inconsistent with how other systems install their data. Linux packages install it into /usr/local/lib/pkgconfig or /usr/lib/pkgconfig, which our pkgconfig doesn't search.
+The pkgconf program already looks in /usr/libdata/pkgconfig and /usr/local/libdata/pkgconfig for data to do its job. It is inconsistent with how other systems install their data. Linux packages install it into /usr/local/lib/pkgconfig or /usr/lib/pkgconfig, which our pkgconfig doesn't search. This may be an orthogonal issue, especially since it is fixed by a one line fix to the port's makefile.
+Alternatively, though, this could be solved with config.site. Another issue is that --prefix is inconsistently used and honored by ports using autoconf's generated configure script. More research may be needed to determine the actual extent of this issue.
+==== Binaries ====
+/usr/local/bin and /usr/local/sbin aren't in the default path (though to be fair, /usr/sbin and /sbin aren't either). So any programs installed by packages won't be found. This is needed for both the default path and the cron path potentially. Perhaps the best solution to this isn't to change the default path in /bin/sh and /bin/csh, but rather add it to the config files .profile and .login used as a template.
 ===== Data from poll / vote =====
@@ Line 76: / Line 82: @@
 There's also concern that arbitrarily adding stuff from /usr/local/ could taint the build of the base system. While we already disable the default includes and libraries when we're building the system (preferring to build them from the source and then using the fresh, uncontaminated bits), not every build system is as careful as %%FreeBSD%%'s. In addition, building individual programs from %%FreeBSD%% would become riskier since they'd be open to contamination from /usr/local. These scenarios aren't too common, but there's no hard data to show just how uncommon they are.
-Julie Mallet reports doing exactly this years ago for a fork of %%FreeBSD%% for one of her customers. The issues were relatively small and easy to diagnose. David Chisnel suggests adding it because he's "...spent far too much of the last 15 years helping non-%%FreeBSD%% developers work around this and trying to persuade them that, if they get past the stage of '%%FreeBSD%% can't even find libraries that it installed,' the system has enough positive attributes that they should spend time learning it."
+Julie Mallet reports doing exactly this years ago for a fork of %%FreeBSD%% for one of her customers. The issues were relatively small and easy to diagnose. David Chisnel suggests adding it because he's spent a lot of time helping "... non-%%FreeBSD%% developers work around this and trying to persuade them that, if they get past the stage of '%%FreeBSD%% can't even find libraries that it installed,' the system has enough positive attributes that they should spend time learning it."
+==== Portsmgr history ====
+Portsmgr consider this [[https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=135089|in this PR]]. The notion was to add it in bsd.ports.mk so individual ports would need to cope. At the end of the day, the consensus was that bsd.ports.mk was the wrong place to do this, and individual ports would be corrected as needed.
 ===== Path Forward =====