1 |
On Thu, 21 Aug 2008 16:35:18 +0100 |
2 |
Steve Long <slong@××××××××××××××××××.uk> wrote: |
3 |
> Hmm fun as it isn't playing these games with you.. |
4 |
|
5 |
What? Deliberately arguing against an idea because it comes from the |
6 |
wrong people, even though they're the only ones with the practical |
7 |
experience on the issue? |
8 |
|
9 |
> > Any reason you can provide for src_configure being useful can be |
10 |
> > used with slight modification for src_prepare. |
11 |
> > |
12 |
> Which is no reason to add a new phase. OFC if zac wants to provide it |
13 |
> that's entirely up to him. |
14 |
|
15 |
Are you saying it is entirely up to him or that it should be entirely |
16 |
up to him? |
17 |
|
18 |
> >> Yeah I've always seen src_unpack as being more cogent to |
19 |
> >> preparation of src files, than to actually untarring stuff. |
20 |
> > |
21 |
> > Yes, the 'unpack' in the name really does go along with the phase |
22 |
> > being used to prepare things. |
23 |
> > |
24 |
> Oh so this is about correct nomenclature rather than anything else? I |
25 |
> see. |
26 |
|
27 |
It's about making the ebuild language fit what most ebuilds do. |
28 |
|
29 |
> > Make a phase for each common logically distinct operation. Which, |
30 |
> > with src_prepare being added, we almost have. |
31 |
> > |
32 |
> Yes, I see, because it's really needed; real functionality our users |
33 |
> have been crying out for. |
34 |
|
35 |
This one's a developer-targeted feature. The benefit to users is that |
36 |
a) developers have a nicer package format to work with, and b) when |
37 |
they want to add patches to an ebuild locally, they don't have to know |
38 |
how to reimplement src_unpack correctly. |
39 |
|
40 |
> > (The one missing is a src_fetch_extra or somesuch, for use by the |
41 |
> > scm eclasses. But that wants special handling, and is probably best |
42 |
> > left to another EAPI...) |
43 |
> > |
44 |
> Yes, a defined, configurable API for dealing with any version control |
45 |
> would be useful, though your minion seemed to argue against it in |
46 |
> #-portage. I can think of a couple of things that would be more |
47 |
> useful to end-users: pkg_check for interactive ebuilds (eg license |
48 |
> acceptance or media access), proper support for cross-compiling, |
49 |
> integration of prefix, better handling of overlays, and of binpkgs.. |
50 |
|
51 |
And all of those are complicated features that can't be delivered with |
52 |
ten minutes work, which would mean delaying EAPI 2. |
53 |
|
54 |
> > Well, if you're proposing that Gentoo also adopts the more |
55 |
> > complicated default_* functions from exheres-0, you're more than |
56 |
> > welcome to write up a proposal... |
57 |
> > |
58 |
> Tsk of course not. default functions are in the pipeline in any case, |
59 |
> but glad to see you're still using this list for proselytising your |
60 |
> pet project while avoiding true discussion. |
61 |
|
62 |
You misunderstand, again. Exheres has two improvements on default |
63 |
functions: the default_*/default mechanism, and better default_ |
64 |
implementations. Portage is taking only the former for EAPI 2. |
65 |
|
66 |
> In any event, it wouldn't be needed. |
67 |
|
68 |
Sure. You can do away with all the helpers and all the default |
69 |
functions in a future EAPI if you want. But all that'd do is make |
70 |
writing correct ebuilds much more tedious. Or, you can go the other |
71 |
way, as Exheres has, and improve the current lot of defaults to make |
72 |
writing ebuilds even easier. |
73 |
|
74 |
> The reasoning others have given (yes it is possible to explain why |
75 |
> without making people read thru 20 one line emails) is that this |
76 |
> would be useful for live ebuilds. |
77 |
|
78 |
Neither src_configure nor src_prepare makes much difference to live |
79 |
ebuilds. |
80 |
|
81 |
> Call the function what you like (or add a new phase with the hooks) |
82 |
> it's still logically one point in time. For a live ebuild it's to |
83 |
> prepare the src, for a normal one to (possibly) unpack and prepare. |
84 |
|
85 |
Uhm. I think you're completely misunderstanding src_prepare. Go back |
86 |
and read the original email. If that's not clear enough for you, also |
87 |
have a look at how it's being used in Exherbo -- you can see plenty of |
88 |
practical examples. Then, once you've done so, please explain how the |
89 |
added simplicity and clarity is not a benefit. |
90 |
|
91 |
-- |
92 |
Ciaran McCreesh |