| 1 |
Jason Stubbs wrote: |
| 2 |
> So to summarise prefixed install support thus far: |
| 3 |
<snip> |
| 4 |
> 2 Portage needs to be enhanced with new ebuild support functions for |
| 5 |
> detecting the location of a dependency. |
| 6 |
|
| 7 |
Did you intend this to be needed for those deps to be installed from the |
| 8 |
ebuild-tree into the same prefix, or for external deps to be |
| 9 |
provided by the system (fex libc, kernel-headers and the like) ? |
| 10 |
|
| 11 |
For the former, `portageq` or even ${PREFIX} should work, |
| 12 |
for the latter, why are package.provides (aka injections) insufficient ? |
| 13 |
|
| 14 |
Well, one could think of some kind of portage-plugins for querying |
| 15 |
external package managers, fex a wrapper to query the rpm-database |
| 16 |
(app-portage/portageq-rpm, selected by profile), and you might need |
| 17 |
them for home-support, but not necessarily for prefix-support. |
| 18 |
|
| 19 |
> 6 Portage must disallow the creation of binary packages where all |
| 20 |
> dependencies are not in the same PREFIX. |
| 21 |
|
| 22 |
Hmm, libc, and at least kernel-headers, might rarely be in the same |
| 23 |
prefix but they are provided (injected), but why not build a binary |
| 24 |
package if so ? |
| 25 |
Of course, a binary-package has to be marked with sth. like the |
| 26 |
target-triplet "${CTARGET:-${CHOST}}" and PREFIX it was built for. |
| 27 |
|
| 28 |
> 7 Portage needs to be able to configured with one-way dependency allowance |
| 29 |
> between installed package databases. For example, ~ installed packages are |
| 30 |
> allowed to depend on / installed packages. |
| 31 |
|
| 32 |
To get this work, imo the portage-plugins to query external pkg-mgr's |
| 33 |
are required (see item 2 above), as '/' might not be managed by portage. |
| 34 |
|
| 35 |
> So unless it is shown otherwise, home install support requires: |
| 36 |
|
| 37 |
But imo the home-support _really_ requires another glep, as there |
| 38 |
are lots of more issuses than for the prefix-support. |
| 39 |
|
| 40 |
~haubi |
| 41 |
-- |
| 42 |
Michael Haubenwallner SALOMON Automation GmbH |
| 43 |
Forschung & Entwicklung A-8114 Friesach bei Graz |
| 44 |
mailto:michael.haubenwallner@×××××××.at http://www.salomon.at |
| 45 |
No HTML/MIME please, see http://expita.com/nomime.html |
| 46 |
-- |
| 47 |
gentoo-dev@g.o mailing list |
Archives