1 |
On Thursday 19 May 2005 17:18, Michael Haubenwallner wrote: |
2 |
> Jason Stubbs wrote: |
3 |
> > 2 Portage needs to be enhanced with new ebuild support functions for |
4 |
> > detecting the location of a dependency. |
5 |
> |
6 |
> Did you intend this to be needed for those deps to be installed from the |
7 |
> ebuild-tree into the same prefix, or for external deps to be |
8 |
> provided by the system (fex libc, kernel-headers and the like) ? |
9 |
|
10 |
I intend that the package to be installed should not assume anything about |
11 |
where its dependencies are and should query portage for them all. Requiring |
12 |
ebuilds to have special handling for when their dependencies are in the same |
13 |
${PREFIX} and when in a different ${PREFIX} just seems crazy to me. |
14 |
|
15 |
> For the former, `portageq` or even ${PREFIX} should work, |
16 |
> for the latter, why are package.provides (aka injections) insufficient ? |
17 |
|
18 |
If portage doesn't tell the packages what to build against, they'll go their |
19 |
own merry way which would definitely make the binary packages mentioned below |
20 |
impossible. |
21 |
|
22 |
> Well, one could think of some kind of portage-plugins for querying |
23 |
> external package managers, fex a wrapper to query the rpm-database |
24 |
> (app-portage/portageq-rpm, selected by profile), and you might need |
25 |
> them for home-support, but not necessarily for prefix-support. |
26 |
|
27 |
Until portage supports other package formats, an equivalent of |
28 |
package.provided would be used for this. However, this has nothing to do with |
29 |
how ebuilds would find out where their dependencies are. |
30 |
|
31 |
> > 6 Portage must disallow the creation of binary packages where all |
32 |
> > dependencies are not in the same PREFIX. |
33 |
> |
34 |
> Hmm, libc, and at least kernel-headers, might rarely be in the same |
35 |
> prefix but they are provided (injected), but why not build a binary |
36 |
> package if so ? |
37 |
> Of course, a binary-package has to be marked with sth. like the |
38 |
> target-triplet "${CTARGET:-${CHOST}}" and PREFIX it was built for. |
39 |
|
40 |
I talked with Brian about this and it does seem reasonable. However, the |
41 |
implementation details will be complex to say the least. |
42 |
|
43 |
> > 7 Portage needs to be able to configured with one-way dependency |
44 |
> > allowance between installed package databases. For example, ~ installed |
45 |
> > packages are allowed to depend on / installed packages. |
46 |
> |
47 |
> To get this work, imo the portage-plugins to query external pkg-mgr's |
48 |
> are required (see item 2 above), as '/' might not be managed by portage. |
49 |
|
50 |
No need to jump to implementation details yet. You haven't scoped out the full |
51 |
requirements yet. |
52 |
|
53 |
> > So unless it is shown otherwise, home install support requires: |
54 |
> |
55 |
> But imo the home-support _really_ requires another glep, as there |
56 |
> are lots of more issuses than for the prefix-support. |
57 |
|
58 |
This is just silly, in my opinion. Home-support may have issues beyond |
59 |
prefix-support, but most of them are the same. Why would you only want to |
60 |
consider prefix-support and implement it if considering home-support might |
61 |
invalidate assumptions you make? Doing this pathspec stuff is a huge project |
62 |
so it's not something that should be rushed into. |
63 |
|
64 |
Doing it properly should also lay down most of the ground work for getting |
65 |
full cross-compile support into portage as well. Personally, I wouldn't push |
66 |
this GLEP for approval at all until those issues are at least looked and |
67 |
fleshed out a bit as well. |
68 |
|
69 |
I'll reiterate; doing this is a huge amount of work. There really needs to be |
70 |
a guarantee that the effort will be worth it. And to be honest, if the only |
71 |
benefit is prefix-support then most everybody will consider the effort to |
72 |
outweigh the return. |
73 |
|
74 |
Regards, |
75 |
Jason Stubbs |