1 |
Alec Warner wrote: |
2 |
|
3 |
> At least one has...do you want to vote for each feature? What will it |
4 |
> take to convince you? |
5 |
> |
6 |
It's not up to me, and I've already conceded on IRC that the consensus is |
7 |
against me (just letting others know); that's life *shrug* |
8 |
|
9 |
>>> (The one missing is a src_fetch_extra or somesuch, for use by the scm |
10 |
>>> eclasses. But that wants special handling, and is probably best left to |
11 |
>>> another EAPI...) |
12 |
>>> |
13 |
>> Yes, a defined, configurable API for dealing with any version control |
14 |
>> would be useful, though your minion seemed to argue against it in |
15 |
>> #-portage. I can think of a couple of things that would be more useful to |
16 |
>> end-users: pkg_check for interactive ebuilds (eg license acceptance or |
17 |
>> media access), proper support for cross-compiling, integration of prefix, |
18 |
>> better handling of overlays, and of binpkgs.. |
19 |
>> |
20 |
> |
21 |
> Your comment is arguably about feature prioritization; not about |
22 |
> whether a given feature is necessary. |
23 |
> |
24 |
> If we have two orthogonal features A and B; you can't argue that A is |
25 |
> necessary and B is not because A is more important to work on; the |
26 |
> only thing you have succeeded in doing is arguing that A should be |
27 |
> done first. |
28 |
> |
29 |
My point was that pkg_check has been requested from years ago, and focus (on |
30 |
the ml, not in terms of what gets done on portage) over the last year or so |
31 |
seems to be much more on things which make it easier for devs to work on |
32 |
live ebuilds (not surprising with kde-4) not on stuff which would make the |
33 |
end-user experience easier, which is what would bring more new users (and |
34 |
thus new devs) in. Both are important, but making your users' lives easier |
35 |
means less support burden, which means you get more time to play with shiny |
36 |
new (aka 'broken') code. |
37 |
|
38 |
Further, I think it would be cleaner if the package manager had a defined |
39 |
configuration to deal with any version control system via an eclass, |
40 |
meaning adding a new one would simply be a case of adding the .eclass to |
41 |
the tree and the eclass name to a profile, with no changes at all required |
42 |
in the mangler, beyond support for the base API (which is in any event |
43 |
handled by bash.) |
44 |
|
45 |
Eclass versioning would be nice too. |
46 |
|
47 |
>> In maintenance terms (when looking at the |
48 |
>> lifecycle of an ebuild) I don't see the need, since there is no unpacking |
49 |
>> required from a vcs pull. Once it's made into a normal ebuild, any |
50 |
>> preparation would necessarily require review and might not be needed at |
51 |
>> all. |
52 |
>> |
53 |
>> Call the function what you like (or add a new phase with the hooks) it's |
54 |
>> still logically one point in time. For a live ebuild it's to prepare the |
55 |
>> src, for a normal one to (possibly) unpack and prepare. |
56 |
>> |
57 |
>> src_configure is a logically distinct action which warrants a new phase, |
58 |
>> since the e*conf call in compile makes retrying a long build (without |
59 |
>> having to recompile stuff which doesn't need it) much more difficult; its |
60 |
>> absence prevents full use of make. Prepare does not warrant a new phase |
61 |
>> imo since it should only be run once per compilation instance; anything |
62 |
>> it does can either be done in unpack, or in configure should that be more |
63 |
>> useful. |
64 |
> |
65 |
> src_prepare is a logically distinct action (maybe if we called it |
66 |
> src_patch it would be clearer?) |
67 |
Er no you're fine, I've been thinking of it as src_patch for quite a while |
68 |
now. |
69 |
|
70 |
> Certainly we only want to patch sources once every time we want to |
71 |
> build a package; what if patching is expensive? |
72 |
> |
73 |
Indeed, that was my point above; it only needs to be done once per instance, |
74 |
whereas configure is something that might well be done more than once. How |
75 |
does that change by having it in unpack (which is empty for a live vcs pull |
76 |
in any case)? |
77 |
|
78 |
Also, if you added support for declarative patches, I think you'd soon end |
79 |
up in a similar situation as with unpack, where there simply isn't a need |
80 |
for the ebuild author to write their own in the vast majority of cases. |
81 |
Thing is you'd then be stuck with a new phase and unable to withdraw it, |
82 |
cos it "only took 10 minutes to add." |
83 |
|
84 |
> The point being the same argument that is for src_configure (that it |
85 |
> is expensive and adding it makes ebuilds clearer) could be said for |
86 |
> src_prepare (preparation could be expensive and it makes ebuilds |
87 |
> clearer). |
88 |
> |
89 |
The compelling argument for configure isn't that it's clearer (although it |
90 |
helps): it's that not having it makes it _impossible_ to restart an ebuild |
91 |
which uses the standard configure make cycle, say if the user has turned |
92 |
off collision-protect in order to get OpenOffice to install, or as recently |
93 |
highlighted in #-dev-help, for an ebuild dev to do the same, via |
94 |
FEATURES=noclean ebuild package.ebuild install. |
95 |
|
96 |
Presumably that's the root cause of "confusion over where to put |
97 |
eautoreconf," since putting it in unpack and not compile gets round the |
98 |
issue. |
99 |
|
100 |
> So why again should we not add it? |
101 |
> |
102 |
I have no issue with the function being part of the EAPI; adding it as a |
103 |
_phase_ seems less wise, but like I said, I accept the consensus is against |
104 |
me. |