On Thu, 21 Aug 2008 16:35:18 +0100
Steve Long <slong@...> wrote:
> Hmm fun as it isn't playing these games with you..

What? Deliberately arguing against an idea because it comes from the
wrong people, even though they're the only ones with the practical
experience on the issue?

> > Any reason you can provide for src_configure being useful can be
> > used with slight modification for src_prepare.
> >
> Which is no reason to add a new phase. OFC if zac wants to provide it
> that's entirely up to him.

Are you saying it is entirely up to him or that it should be entirely
up to him?

> >> Yeah I've always seen src_unpack as being more cogent to
> >> preparation of src files, than to actually untarring stuff.
> > 
> > Yes, the 'unpack' in the name really does go along with the phase
> > being used to prepare things.
> >
> Oh so this is about correct nomenclature rather than anything else? I
> see. 

It's about making the ebuild language fit what most ebuilds do.

> > Make a phase for each common logically distinct operation. Which,
> > with src_prepare being added, we almost have.
> >
> Yes, I see, because it's really needed; real functionality our users
> have been crying out for.

This one's a developer-targeted feature. The benefit to users is that
a) developers have a nicer package format to work with, and b) when
they want to add patches to an ebuild locally, they don't have to know
how to reimplement src_unpack correctly.

> > (The one missing is a src_fetch_extra or somesuch, for use by the
> > scm eclasses. But that wants special handling, and is probably best
> > left to another EAPI...)
> >
> Yes, a defined, configurable API for dealing with any version control
> would be useful, though your minion seemed to argue against it in
> #-portage. I can think of a couple of things that would be more
> useful to end-users: pkg_check for interactive ebuilds (eg license
> acceptance or media access), proper support for cross-compiling,
> integration of prefix, better handling of overlays, and of binpkgs..

And all of those are complicated features that can't be delivered with
ten minutes work, which would mean delaying EAPI 2.

> > Well, if you're proposing that Gentoo also adopts the more
> > complicated default_* functions from exheres-0, you're more than
> > welcome to write up a proposal...
> >
> Tsk of course not. default functions are in the pipeline in any case,
> but glad to see you're still using this list for proselytising your
> pet project while avoiding true discussion. 

You misunderstand, again. Exheres has two improvements on default
functions: the default_*/default mechanism, and better default_
implementations. Portage is taking only the former for EAPI 2.

> In any event, it wouldn't be needed.

Sure. You can do away with all the helpers and all the default
functions in a future EAPI if you want. But all that'd do is make
writing correct ebuilds much more tedious. Or, you can go the other
way, as Exheres has, and improve the current lot of defaults to make
writing ebuilds even easier.

> The reasoning others have given (yes it is possible to explain why
> without making people read thru 20 one line emails) is that this
> would be useful for live ebuilds.

Neither src_configure nor src_prepare makes much difference to live
ebuilds.

> Call the function what you like (or add a new phase with the hooks)
> it's still logically one point in time. For a live ebuild it's to
> prepare the src, for a normal one to (possibly) unpack and prepare.

Uhm. I think you're completely misunderstanding src_prepare. Go back
and read the original email. If that's not clear enough for you, also
have a look at how it's being used in Exherbo -- you can see plenty of
practical examples. Then, once you've done so, please explain how the
added simplicity and clarity is not a benefit.

-- 
Ciaran McCreesh