Date: Wed, 28 Mar 2001 15:06:17 -0500 (EST) From: Trevor Johnson <trevor@jpj.net> To: <ports@FreeBSD.ORG> Cc: Mike Myers <mwm@mired.org> Subject: Re: /usr/local abuse Message-ID: <20010328133451.Y27705-100000@blues.jpj.net> In-Reply-To: <20001210135125.B82246@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I'm following up to an old thread from -current, about installing ports and packages in places other than /usr/local/. On 10 December 2000, David O'Brien wrote: > On Sun, Dec 10, 2000 at 12:26:38PM -0800, Joe Kelsey wrote: > > This thread is also about a completely separate issue, which is a > > deficiency in the package command used on FreeBSD. The basic problem > > with pkg_add et al., as opposed to, for instance, SVR4 pkgadd, is that > > it does not allow the local administrator to change the installation > > directory. > > pkg_add *does* allow the installer to choose the installation > directory -- the "-p" option. The issue is one of *compiled* in paths. > So if Satoshi builds port foobar (which as a config file etc/foobar.conf) > then the foobar binary has "/usr/local/etc" burned into it because that > is what Satoshi had PREFIX set to. 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 For type 1, there is no problem, obviously. For type 2, the existence of a compiled-in path should often be detectable by preparing the package with a special prefix, then grepping the contents of the package for that prefix. If the file with the burned-in path got compressed (probably rare), then that test wouldn't work. A more expensive test could confirm that the package is not type 2: compile two packages, with different settings for PREFIX, and compare the contents of the files. If they were identical, then we have type 1 or type 3. If they differ, it could be because they have a compiled-in path, or because something like the time of day was compiled in. At yet greater expense we can identify packages that have the time of day compiled in: compile a third time with a PREFIX identical to one already used, and compare the results. If they are the same, we have a type 2 package. If they are different, it could still be type 2, but there's definitely something else going on. 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". 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. -- Trevor Johnson (who has a type 3 port) 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?20010328133451.Y27705-100000>