| 1 |
On Thu, May 14, 2020 at 09:26:10AM -0400, Michael Orlitzky wrote: |
| 2 |
> On 5/14/20 7:55 AM, Neil Bothwick wrote: |
| 3 |
> > On Thu, 14 May 2020 18:17:06 +0800, Pengcheng Xu wrote: |
| 4 |
> > |
| 5 |
> >> That seems interesting. Do we need to include Portage install prefix |
| 6 |
> >> (/var/tmp/portage/category/package/..., the image path prefix before |
| 7 |
> >> actually merging with /)? |
| 8 |
> >> |
| 9 |
> >> Regards, |
| 10 |
> > |
| 11 |
> > No, just the --prefix=/home/blah/ that you want added to the ./configure |
| 12 |
> > invocation. |
| 13 |
> > |
| 14 |
> |
| 15 |
> This is a good way to install packages that you've built by hand into |
| 16 |
> (say) your home directory, but it will cause problems if you try to |
| 17 |
> trick portage into doing it. The big problem is that no other packages |
| 18 |
> are going to know where to find the thing you just installed. Everything |
| 19 |
> else in the Gentoo repository is designed to use standard values of |
| 20 |
> PATH, LD_LIBRARY_PATH, the compiler's include dir, PKG_CONFIG_PATH, etc. |
| 21 |
> If you take one program and put it somewhere non-standard, then every |
| 22 |
> package depending on it is going to break. |
| 23 |
> |
| 24 |
> If you install an *additional* copy (built by hand) in your home |
| 25 |
> directory, that's fine -- the system copy will still be in the right |
| 26 |
> place -- you just don't want to hide the system copy where nobody can |
| 27 |
> find it. |
| 28 |
> |
| 29 |
|
| 30 |
In my case, this wouldn't be a problem: I don't want the packages to be |
| 31 |
accessed by anyone, just one user. I can set PATH, LD_LIBRARY_PATH, |
| 32 |
PKG_CONFIG_PATH and MANPATH for that user. I already do that for things |
| 33 |
I build manually anyway. |
| 34 |
|
| 35 |
EXTRA_ECONF is nice, I didn't know about it. It looks like MYCMAKEARGS |
| 36 |
can be used for cmake ebuilds. For other build systems, it might be |
| 37 |
necessary to edit the ebuild, or set different variables. |
| 38 |
|
| 39 |
I still kinda think that being able to install with a prefix (like |
| 40 |
EPREFIX) but using the base system would be a nice feature. As discussed |
| 41 |
previously, there would be the problem of updates; but it isn't very |
| 42 |
different from installing software manually. If I clone something and |
| 43 |
build it locally, a world update might break break it, and portage |
| 44 |
cannot rebuild it automatically since it's not aware of it. This is why |
| 45 |
I think it would be nice if portage supported it; that way, after an |
| 46 |
update of the base system, updating the prefix system would solve the |
| 47 |
problems. It's probably difficult to implement that in portage, though. |
Archives