Jason Stubbs wrote:
> So to summarise prefixed install support thus far:
<snip>
> 2 Portage needs to be enhanced with new ebuild support functions for
> detecting the location of a dependency.
Did you intend this to be needed for those deps to be installed from the
ebuild-tree into the same prefix, or for external deps to be
provided by the system (fex libc, kernel-headers and the like) ?
For the former, `portageq` or even ${PREFIX} should work,
for the latter, why are package.provides (aka injections) insufficient ?
Well, one could think of some kind of portage-plugins for querying
external package managers, fex a wrapper to query the rpm-database
(app-portage/portageq-rpm, selected by profile), and you might need
them for home-support, but not necessarily for prefix-support.
> 6 Portage must disallow the creation of binary packages where all
> dependencies are not in the same PREFIX.
Hmm, libc, and at least kernel-headers, might rarely be in the same
prefix but they are provided (injected), but why not build a binary
package if so ?
Of course, a binary-package has to be marked with sth. like the
target-triplet "${CTARGET:-${CHOST}}" and PREFIX it was built for.
> 7 Portage needs to be able to configured with one-way dependency allowance
> between installed package databases. For example, ~ installed packages are
> allowed to depend on / installed packages.
To get this work, imo the portage-plugins to query external pkg-mgr's
are required (see item 2 above), as '/' might not be managed by portage.
> So unless it is shown otherwise, home install support requires:
But imo the home-support _really_ requires another glep, as there
are lots of more issuses than for the prefix-support.
~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
