Date: Wed, 28 Mar 2001 17:42:02 -0600 From: Mike Meyer <mwm@mired.org> To: Trevor Johnson <trevor@jpj.net> Cc: <ports@FreeBSD.ORG>, Anton Berezin <tobez@tobez.org> Subject: Re: /usr/local abuse Message-ID: <15042.30410.581820.501773@guru.mired.org> In-Reply-To: <20010328133451.Y27705-100000@blues.jpj.net> References: <20001210135125.B82246@dragon.nuxi.com> <20010328133451.Y27705-100000@blues.jpj.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Trevor Johnson <trevor@jpj.net> types: > I'm following up to an old thread from -current, about installing ports > and packages in places other than /usr/local/. Thank you for including my email address. For future reference, my last name is "Meyer", not "Myers". > On 10 December 2000, David O'Brien wrote: > I can imagine three different kinds of packages: > > 1) ones with no compiled-in paths > 2) ones with compiled-in paths that vary according to PREFIX > 3) ones with compiled-in paths which ignore PREFIX > > Type 3 is not prefix-safe even as a port. If we're really supporting > different prefixes, it should be marked broken. Because few of us > actually use prefixes besides /usr/local/, and /usr/local/ is the default > for much of the ported software as its authors ship it, there are probably > a lot of type 3 ports which aren't marked broken. A heuristic for > detecting them would be to compile a package with a special prefix, use > hier(7) and permissions to guess which files in it are commands or > configuration files, then grep around in them for "usr/local". As someone who runs with LOCALBASE (and hence PREFIX) not equal to /usr/local, I can report that "lots" is fewer than 1000, and possibly fewer than 450. I seem to hit around 10% being broken. However, I'm not a perl programmer, and tend to ignore perl modules - which are nearly uniformly type 3 ports. Anton's BSDPAN package is an excellent solution to that problem. Also, with the exception of the Perl stuff, most maintainers have been very responsive about fixing problems in their ports - especially if I supply patches :-). > Once we're done distinguishing type 1, 2 or 3, what could we do with the > information? For type 1, nothing need be done. For type 2, the packages > could be discarded, or they could be marked in some way to alert the user > that they are prefix-dependent. Perhaps the name of the package could > have special text in it, "-prefixdirty" for example, and pkg_add would > error out if it were asked to install a package with that in the name, > when given the -p option. For type 3, the maintainer of the port should > be asked to fix the port or mark it broken. > > If all this is too much trouble, complexity, and expense, the honest thing > would be to say we only support the default prefix. There's an interesting twist to this problem when you start looking at dependencies between ports. In this case, LOCALBASE is the thing that becomes compiled in. If I build and install Aport with LOCALBASE set one way, then change LOCALBASE then build and install Bport, Bport is liable to miss Aport being installed, and try and install Aport again - which will probably fail because /var/db/pkg has recorded Aport as installed. If the install of Aport works, Bport may wind up looking in the wrong place for parts of Aport at run time. Even though I've changed LOCALBASE, I think trying to support arbitrary changes to LOCALBASE and/or PREFIX - especially in packages - is probably "too much trouble, complexity and expense." Unless someone has a simple to incorporate mechanism that allows application directories to be moved at will, anyway. I'd be happy with a mechanism that allows people to set systems up so that ports go somewhere other than /usr/local if they desire. If they want to undo that, or move it somewhere else, it's not unreasonble to ask them to rebuild the installed ports, though doing so on a running system might be an interesting exercise. I'd therefore suggest the following changes and additions to the documentation: 1) A system should have all ports built with LOCALBASE set to the same value. Trying to run ports built with different values of LOCALBASE, or build ports on a system that has other ports built with a different value of LOCALBASE, may well cause breakage, and is discouraged. 2) Many of the default system configuration files have /usr/local wired into them. If you change LOCALBASE, you have to deal with those as well. If this proposal is adopted, this may be fixable - but you have to install the system with LOCALBASE set properly. 3) Packages are built with LOCALBASE set to /usr/local. 4) PREFIX gets changed to LOCALBASE where we document how to change where ports install, along with a pointer to the above warning. This change also happens in the porters handbook. 5) PREFIX for ports and -p for pkg_add are for testing and development purposes only. Note that I've replaced "LOCALBASE-clean" with "PREFIX-clean". LOCALBASE-clean implies PREFIX-clean, and also implies that references to parts of other ports will be done via either LOCALBASE or PREFIX. Personally, I would like the LOCALBASE/PREFIX dichotomy at build time to be that things used at build or install time are from LOCALBASE; things used at run time are from PREFIX. This would allow me - in theory - to build packages for a system with one setting of LOCALBASE to be installed on a system with a different one by setting PREFIX when I build the port. <mike PS - I'm not currently subscribed to ports; please keep me in the cc list. -- Mike Meyer <mwm@mired.org> http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15042.30410.581820.501773>