Frank Peters <frank.pet...@comcast.net> posted 20090430160833.ae6c8e22.frank.pet...@comcast.net, excerpted below, on Thu, 30 Apr 2009 16:08:33 -0400:
> As I understand things, overlays could not be the answer because they > are intended only for packages outside of the standard portage tree. I > want to install some standard packages into an alternative location. Well, yes and no. Anytime you'd modify an ebuild, whether it's a version bump before Gentoo has one or because you want a modified version of whatever normal Gentoo tree package you'd ordinarily use (the case here), you can use an overlay. The reason is simple. Any changes you make to the normal tree get overwritten once you sync it, so to keep your modified ebuilds (and anything else they need, patches, eclasses, etc, if modified) around, you put them in an overlay. IOW it's perfectly usual to simply take an existing ebuild in the normal tree, copy it to your overlay, make a single change (or more than one if needed), and remerge that package so the overlay with the modification is used instead of the normal tree package. The problem is that this doesn't scale so easily if you're modifying say most of your tree. But for a package here or there, it's great. And, you can develop scripts if necessary to automate most of the process, if you're going to be doing more than just a handful of packages, or on a long enough basis you want to hook it in with the normal sync so any new versions are automatically copied over and changes you know need to be made, made. (The problem there is unforeseen changes in the new version, but you can automate the normal stuff and then either have the script tell you to look the thing over before merging, or only worry about it when something goes wrong.) > Since I would only want to relocate a relatively small number of > packages, another solution I am considering is to emerge with the option > --buildpkgonly to create a binary package. This package can then be > unpacked to the desired location. Also, sed can be used to change all > instances of /usr/lib64, /usr/include, etc., in the *.la and *.pc files > to the appropriate directory. The file package.provided would also have > to updated to inform portage that the package is actually available. > This may seem rather tedious, but a shell script could automate the > process. It may not be elegant, but it would work. I hadn't thought of that use of binpkgs, but yes, it should work. =:^) If you're advanced enough at scripting to be thinking about it, then great, and the overlay thing above shouldn't be too bad of a challenge, either. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
