Re: [gentoo-dev] EAPI 3 PMS Draft

[Tiziano Müller]

Thanks a lot for your work.

Am Montag, den 16.03.2009, 20:47 +0000 schrieb Ciaran McCreesh:
> I've got a very rough draft of what EAPI 3 might end up looking like,
> based upon discussion:
>
>     http://github.com/ciaranm/pms/tree/eapi-3
>
> Note that I will probably rebase and modifying the branch quite a bit,
> so if you don't know how to deal with that when using git, don't track
> it.
>
> It should be one commit per feature, which makes it fairly easy to
> remove anything that ends up not making it, and very easy to see what's
> proposed, which currently looks like this:
>
> * Introduce eapi 3
> * Rework tables for EAPI 3.
> * EAPI 3 has pkg_pretend.
> * EAPI 3 supports slot operator dependencies
> * EAPI 3 has use dependency defaults
> * PROPERTIES, DEFINED_PHASES mandatory in EAPI 3
> * EAPI 3 has a default src_install
> * EAPI 3 has controllable compression and docompress
> * EAPI 3 has dodoc -r
> * EAPI 3 requires doins support for symlinks
> * EAPI 3 bans || ( use? ( ... ) )
> * dohard and dosed banned in EAPI 3
> * doinclude, newinclude for EAPI 3
> * EAPI 3 supports .xz, .tar.xz
> * EAPI 3 has more econf arguments
> * EAPI 3 supports pkg_info on installed packages
> * USE is stricter in EAPI 3
> * Note that (+) won't work on USE_EXPAND etc things
> * AA, KV gone in EAPI 3
>
> Still to work out:
>
> * The exact details for the new USE restrictions. In particular, do we
>   want IUSE_IMPLICIT? We'll also need an accurate list of all
>   possible values for things like LINGUAS.
>
> * The [use(+)] thing. For various really pesky reasons, there's no way
>   things like [video_cards_radeon(+)] can be expected to work when
>   applied against EAPIs before 3, but it can be made to work if we know
>   it'll only ever be applied against things with EAPI 3 or later. Is it
>   easier to just say it's never allowed, though?
>
> * What's a doexample?


>
> * What's default_src_install going to do? I've seen a load of
>   variations. It looks like our choices are between things that ignore
>   docs, making it largely worthless, or things that use a DOCS
>   variable, which Donnie hates (despite making extensive use of such
>   things himself in eclasses).
Well, we have distutils and gnome2 eclass using DOCS (to name a few,
short glep shows around 18 eclasses), so I'd say: if we go for a
default_src_install it needs surely DOCS.
If default_src_install should install some DOCS automatically, I'd like
to have a way to disable that behaviour without having to roll my own
src_install.
You forgot to mentioned that we probably also want that
default_src_configure/src_compile die when they try to `cd` to an
invalid ${S}.



>
> * "Provide ebuilds a way to differentiate between updates and
>   removals". I suggested REPLACING_VERSIONS and REPLACED_BY_VERSION,
>   but I've not had any feedback on that.


>
> * "Utility commands, even the ones that aren't functions, should die.".
>   Is Portage likely to be able to do this in the timeframe we're after?
I'd say this is a pretty isolated task even people without in-depth
portage knowledge can work on, so I guess it can be implemented.

>
> * "Calling unpack on an unrecognised extension should be fatal, unless
>   --if-compressed is specified.". There've been questions on this, but
>   no obvious outrage. Is this in or out?
I'd vote for "in" here since I prefer defined behaviour over undefined
and people who want unpack to unpack not-packed files should state it
explicitly.

>
> * I've left out killing off dohtml. Was a decision reached on that?
No.


>
> * RDEPEND=DEPEND is still in. Again, was a decision reached?
No, but since repoman is already warning when no RDEPEND or DEPEND is
specified I guess most people want it to be explicit.


>
> * xz is in, but do we really want to do that when there appears to be
>   nothing stable that can deal with xz? lzma going in was a mistake
>   caused by people being too eager here in exactly the same way they
>   were for making Portage handle xz...
>
> * Am I to take it src_test is to remain in its current worthless state?
Yes, I'd like to see it enable by default as well, but we have to
discuss that further. So, not suited for a fast eapi release.


Btw, I put up a document explaining the changes in some detail here:
http://dev.gentoo.org/~dev-zero/docs/EAPI3.{rst,html}
(including references to bugs if any, etc.)
It is completely based on the spreadsheet we used earlier for
discussion. I'll finish it within the next days.

Cheers,
Tiziano