1 |
Ciaran McCreesh wrote: |
2 |
> On Thu, 19 May 2005 10:18:03 +0200 Michael Haubenwallner |
3 |
> | But imo the home-support _really_ requires another glep, as there |
4 |
> | are lots of more issuses than for the prefix-support. |
5 |
> |
6 |
> Naah. Not really. The hard part is figuring out how to correctly change |
7 |
> all shell scripts that start with #!/bin/sh to use the portage-provided |
8 |
> sh instead, all perl scripts that start with #!/usr/bin/perl or |
9 |
> #!/usr/bin/env perl to use the portage-provided perl instead, how to fix |
10 |
> all autotools checks which look in /usr/lib first and so on. From an |
11 |
> ebuild perspective, which is where most of the work will be, asking |
12 |
> portage just where it *should* look is really just a sidenote that needs |
13 |
> to be documented somewhere. |
14 |
> |
15 |
|
16 |
Here some things imo not needed to mention in the glep: |
17 |
|
18 |
Most of the packages (not ebuilds) wont work on systems without |
19 |
/bin/sh (Bourne-Shell, not bash) and /usr/bin/env, so there's no need to |
20 |
have a Bourne-Shell installed in /my/prefix/bin/sh instead of /bin/sh. |
21 |
|
22 |
When a user wants to use things (including portage) from /my/prefix, |
23 |
he/she has to source /my/prefix/etc/profile (this could be in the glep). |
24 |
|
25 |
Once this is done, this line will find the portage-installed |
26 |
interpreters: |
27 |
#! /usr/bin/env {bash,perl,python,whatever} |
28 |
|
29 |
When portage starts the ebuild-daemon, i've seen that portage removes |
30 |
PATH from environment and lets bash use its default-PATH. |
31 |
|
32 |
So i've added one more patch to bash.ebuild to change the default-PATH |
33 |
to "/my/prefix/bin:/usr/bin:/bin" if prefix!=/usr instead of |
34 |
"/usr/local/bin:/usr/bin:/bin", which is done in bash.ebuild right now. |
35 |
|
36 |
autoconf-checks: i configure gcc '--with-local-prefix=/my/prefix' in |
37 |
case of prefix!=/usr, so gcc searches in "/my/prefix/lib:/usr/lib:/lib" |
38 |
for libraries by default, and the checks should rely on the compiler to |
39 |
find the right libraries when configuring. |
40 |
|
41 |
Another one is ld.so.conf: |
42 |
All of the shlib-loaders know some kind of LD_LIBRARY_PATH in environ, |
43 |
and instead of writing /my/prefix/etc/ld.so.conf, portage puts the |
44 |
LDPATH-bits from env.d/ into this variable, so finding the right |
45 |
shared-libs does work. |
46 |
|
47 |
So at least bash is required to be installed into same prefix as |
48 |
portage, and its easier to have gcc here too instead of setting |
49 |
CPATH and LIBRARY_PATH to /my/prefix/{include,lib} and providing gcc. |
50 |
|
51 |
And it is necessary to have different baselayouts and profiles necessary |
52 |
for different systems (solaris,aix,hpux,...) to keep the differences |
53 |
outside of portage. |
54 |
|
55 |
And for a package (not the ebuild) which cannot install to prefix, it is |
56 |
unlikely that it makes sense to install it besides the primary prefix. |
57 |
|
58 |
~haubi |
59 |
-- |
60 |
Michael Haubenwallner SALOMON Automation GmbH |
61 |
Forschung & Entwicklung A-8114 Friesach bei Graz |
62 |
mailto:michael.haubenwallner@×××××××.at http://www.salomon.at |
63 |
No HTML/MIME please, see http://expita.com/nomime.html |
64 |
-- |
65 |
gentoo-dev@g.o mailing list |