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