Ciaran McCreesh wrote:
> On Thu, 19 May 2005 10:18:03 +0200 Michael Haubenwallner
> | But imo the home-support _really_ requires another glep, as there
> | are lots of more issuses than for the prefix-support.
>
> Naah. Not really. The hard part is figuring out how to correctly change
> all shell scripts that start with #!/bin/sh to use the portage-provided
> sh instead, all perl scripts that start with #!/usr/bin/perl or
> #!/usr/bin/env perl to use the portage-provided perl instead, how to fix
> all autotools checks which look in /usr/lib first and so on. From an
> ebuild perspective, which is where most of the work will be, asking
> portage just where it *should* look is really just a sidenote that needs
> to be documented somewhere.
>
Here some things imo not needed to mention in the glep:
Most of the packages (not ebuilds) wont work on systems without
/bin/sh (Bourne-Shell, not bash) and /usr/bin/env, so there's no need to
have a Bourne-Shell installed in /my/prefix/bin/sh instead of /bin/sh.
When a user wants to use things (including portage) from /my/prefix,
he/she has to source /my/prefix/etc/profile (this could be in the glep).
Once this is done, this line will find the portage-installed
interpreters:
#! /usr/bin/env {bash,perl,python,whatever}
When portage starts the ebuild-daemon, i've seen that portage removes
PATH from environment and lets bash use its default-PATH.
So i've added one more patch to bash.ebuild to change the default-PATH
to "/my/prefix/bin:/usr/bin:/bin" if prefix!=/usr instead of
"/usr/local/bin:/usr/bin:/bin", which is done in bash.ebuild right now.
autoconf-checks: i configure gcc '--with-local-prefix=/my/prefix' in
case of prefix!=/usr, so gcc searches in "/my/prefix/lib:/usr/lib:/lib"
for libraries by default, and the checks should rely on the compiler to
find the right libraries when configuring.
Another one is ld.so.conf:
All of the shlib-loaders know some kind of LD_LIBRARY_PATH in environ,
and instead of writing /my/prefix/etc/ld.so.conf, portage puts the
LDPATH-bits from env.d/ into this variable, so finding the right
shared-libs does work.
So at least bash is required to be installed into same prefix as
portage, and its easier to have gcc here too instead of setting
CPATH and LIBRARY_PATH to /my/prefix/{include,lib} and providing gcc.
And it is necessary to have different baselayouts and profiles necessary
for different systems (solaris,aix,hpux,...) to keep the differences
outside of portage.
And for a package (not the ebuild) which cannot install to prefix, it is
unlikely that it makes sense to install it besides the primary prefix.
~haubi
--
Michael Haubenwallner SALOMON Automation GmbH
Forschung & Entwicklung A-8114 Friesach bei Graz
mailto:[EMAIL PROTECTED] http://www.salomon.at
No HTML/MIME please, see http://expita.com/nomime.html
--
gentoo-dev@gentoo.org mailing list
