1 |
Zac, I think you misunderstood me here. Crosscompile-only HDEPEND is |
2 |
definitely necessary, I've seen many packages need this. But what I'm |
3 |
suggesting is that we also, and maybe only, need "ROOT != /" - only |
4 |
HDEPEND dependencies. This means that the dependency would only be |
5 |
required if the package is being built for a ROOT that is not /. The |
6 |
idea is to eliminate the strange case that is ROOT!=/ but FEATURES has |
7 |
no crosscompile. If the package requires tools that it would build |
8 |
itself if ROOT was /, it will use the host's version of the tool |
9 |
whenever ROOT!=/ It wouldn't have to worry about whether the tools it |
10 |
builds link to libraries in ROOT. |
11 |
|
12 |
So my proposal is basically, instead of: |
13 |
HDEPEND="crosscompile? ( ~${CATEGORY}/${P} ) (yes, that seems to be |
14 |
the most common case) |
15 |
|
16 |
there would also, and maybe only, be: |
17 |
HDEPEND="root_not_slash? ( ~${CATEGORY}/${P} )" |
18 |
|
19 |
root_not_slash (or another name) would essentially be a superset of |
20 |
crosscompile, since crosscompile implies ROOT!=/. |
21 |
|
22 |
P.S. sorry Zac I sent you this twice, damn GMail :) |
23 |
|
24 |
On Sat, Sep 22, 2012 at 6:31 PM, Zac Medico <zmedico@g.o> wrote: |
25 |
> On 09/22/2012 09:08 AM, Ambroz Bizjak wrote: |
26 |
>> Yes, I think this is a good idea, it would allow the dependencies to |
27 |
>> be expressed nicely as conditions. |
28 |
>> |
29 |
>> But I'm not sure how this would be a USE flag. It should behave like |
30 |
>> one during the build, but it would be best if it was not written into |
31 |
>> the VDB as such, at least in a way that would be considered by |
32 |
>> --newuse. It don't want "emerge -unD" on the booted system want to |
33 |
>> reinstall all packages because the current ones were cross-compiled. |
34 |
>> Does the test flag already behave nicely like that? In that case, all |
35 |
>> is good, and I can try to implement this. |
36 |
> |
37 |
> Simply add your special flag to the _feature_flags variable in |
38 |
> config.py, and it will be exempt from --newuse. See this commit: |
39 |
> |
40 |
> http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=6b19f71b39b6af43307abf20654511bace041217 |
41 |
> |
42 |
>> On a slightly different subject: I've been porting some packages to |
43 |
>> HDEPEND and I've seen problems with packages that want to use the |
44 |
>> programs they build during the build (or in postinst). Of couse this |
45 |
>> works for native builds, and it can be fixed to work for cross-compile |
46 |
>> builds (build native version or HDEPEND on host package). |
47 |
>> |
48 |
>> But what do we do with the strange case where ROOT!=/ but |
49 |
>> --crosscompile/FEATURES=crosscompile is not in affect? Can we expect |
50 |
>> that we will be able to run the programs that were built? What if they |
51 |
>> link to libraries only available in ROOT? |
52 |
>> |
53 |
>> So, I think it would make sense for a lot of packages to treat ROOT!=/ |
54 |
>> equivalently to cross-compilation, i.e. require host tool to be |
55 |
>> present. But with what has currently been proposed there is no |
56 |
>> conditional dependency on ROOT!=/, so a package cannot demand that a |
57 |
>> tool be present on the host. Then, it may be a good idea to add a |
58 |
>> conditional dependency on ROOT!=/. |
59 |
> |
60 |
> If I understand correctly, that would be like a CROSS_TDEPEND? If we |
61 |
> translate that to a conditional, it would become DEPEND="crosscompile? ( |
62 |
> foo )", since our plan was to make DEPEND apply to ROOT!=/ and HDEPEND |
63 |
> apply to ROOT=/, right? |
64 |
> |
65 |
>> In fact, I think that --crosscompile or FEATURES=crosscompile could |
66 |
>> actually be abolished and only this condition would be available. It's |
67 |
>> true that some packages would only use the host dependency if there's |
68 |
>> actual cross-compilation going on, but nothing will break. This would |
69 |
>> ease configuration and reduce the number of cases to be tested. |
70 |
> |
71 |
> Yeah, the split between HDEPEND and DEPEND might be enough so that you |
72 |
> don't need these conditionals. If you're not really sure that the |
73 |
> conditionals are needed, then maybe it's better to eliminate them for now. |
74 |
> -- |
75 |
> Thanks, |
76 |
> Zac |