FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 03-16-2009, 07:47 PM
Ciaran McCreesh
 
Default EAPI 3 PMS Draft

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).

* "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?

* "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've left out killing off dohtml. Was a decision reached on that?

* RDEPEND=DEPEND is still in. Again, was a decision reached?

* 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?

I've probably missed some more things, but I don't know what they are,
so if anyone can find any please list them.

--
Ciaran McCreesh
 
Old 03-16-2009, 09:59 PM
Maciej Mrozowski
 
Default EAPI 3 PMS Draft

On Monday 16 of March 2009 21:47:17 Ciaran McCreesh wrote:
> I've got a very rough draft of what EAPI 3 might end up looking like,
> based upon discussion:
[cut]

Nice work.
To avoid further confusion I'd suggest removing all traces of kdebuild- format
and its features (like PDEPEND labels, ranged dependencies) from PMS document,
especially its references to Gentoo KDE project.
It has not been accepted thus should not exist in "Gentoo PMS" document.

> * RDEPEND=DEPEND is still in. Again, was a decision reached?

Imho it would be about time to kill implicit build time dependency assignment.

--
regards
MM


----------------------------------------------------------------------
Udar sloneczny prezesa Kaczynskiego... >>> http://link.interia.pl/f2083
 
Old 03-16-2009, 10:09 PM
Rmi Cardona
 
Default EAPI 3 PMS Draft

Le 16/03/2009 23:59, Maciej Mrozowski a crit :

* RDEPEND=DEPEND is still in. Again, was a decision reached?


Imho it would be about time to kill implicit build time dependency assignment.


+1, let's rip it out.

Rmi
 
Old 03-16-2009, 10:20 PM
Ciaran McCreesh
 
Default EAPI 3 PMS Draft

On Mon, 16 Mar 2009 23:59:45 +0100
Maciej Mrozowski <reavertm@poczta.fm> wrote:
> To avoid further confusion I'd suggest removing all traces of
> kdebuild- format and its features (like PDEPEND labels, ranged
> dependencies) from PMS document, especially its references to Gentoo
> KDE project. It has not been accepted thus should not exist in
> "Gentoo PMS" document.

Why? It was an official EAPI agreed upon by the Gentoo KDE project.
Having it there is helpful for package manager people, and removing it
would just mean more work when features make their way into Portage.
Besides, if you really don't want to see it, you can just make it all
invisible with one easy switch.

We've been over all this before. Unless you have something new to add,
kindly avoid wasting people's time.

--
Ciaran McCreesh
 
Old 03-16-2009, 10:22 PM
Tiziano Mller
 
Default EAPI 3 PMS Draft

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
 
Old 03-16-2009, 10:26 PM
Tomáš Chvátal
 
Default EAPI 3 PMS Draft

Dne úterý 17 Březen 2009 00:20:11 Ciaran McCreesh napsal(a):
> On Mon, 16 Mar 2009 23:59:45 +0100
>
> Maciej Mrozowski <reavertm@poczta.fm> wrote:
> > To avoid further confusion I'd suggest removing all traces of
> > kdebuild- format and its features (like PDEPEND labels, ranged
> > dependencies) from PMS document, especially its references to Gentoo
> > KDE project. It has not been accepted thus should not exist in
> > "Gentoo PMS" document.
>
> Why? It was an official EAPI agreed upon by the Gentoo KDE project.
> Having it there is helpful for package manager people, and removing it
> would just mean more work when features make their way into Portage.
> Besides, if you really don't want to see it, you can just make it all
> invisible with one easy switch.
>
Actualy now people expect kde team to manage support for kdebuild too. So it
is not such crazy request.

> We've been over all this before. Unless you have something new to add,
> kindly avoid wasting people's time.

And you are not wasting others time by flaming all around glep 54. I dont mean
i dont agree with the glep i just dont agree with your way promoting it. And
if you say i dont have to read all the long flame around you dont have the
right saying somebody else not to write his ideas on this mailing list.
 
Old 03-16-2009, 10:35 PM
Ciaran McCreesh
 
Default EAPI 3 PMS Draft

On Tue, 17 Mar 2009 00:26:36 +0100
Tomáš Chvátal <scarabeus@gentoo.org> wrote:
> > Why? It was an official EAPI agreed upon by the Gentoo KDE project.
> > Having it there is helpful for package manager people, and removing
> > it would just mean more work when features make their way into
> > Portage. Besides, if you really don't want to see it, you can just
> > make it all invisible with one easy switch.
> >
> Actualy now people expect kde team to manage support for kdebuild
> too. So it is not such crazy request.

There's a lot of kdebuild-1 stuff still out there that the Gentoo KDE
team created, and that users used because it was the best option at
the time. You can't pretend it never existed. And remember, a package
manager can't correctly uninstall something unless it knows about the
installed package's EAPI.

> > We've been over all this before. Unless you have something new to
> > add, kindly avoid wasting people's time.
>
> And you are not wasting others time by flaming all around glep 54. I
> dont mean i dont agree with the glep i just dont agree with your way
> promoting it. And if you say i dont have to read all the long flame
> around you dont have the right saying somebody else not to write his
> ideas on this mailing list.

There has yet to be a decent technical objection to kdebuild-1
being in PMS. There has yet to be a decent technical objection to GLEP
54. Anyone going around objecting to either without bringing new
material to the table is either trolling or hasn't done their homework.

The nature of Gentoo management is such that any unanswered objection
is treated as legitimate grounds to stall a proposal indefinitely, even
if that objection has been answered ten times previously. I really
don't want to see the Council sit around and not approve EAPI 3 until
we have the whole kdebuild discussion again.

--
Ciaran McCreesh
 
Old 03-16-2009, 10:51 PM
Ryan Hill
 
Default EAPI 3 PMS Draft

On Tue, 17 Mar 2009 00:22:36 +0100
Tiziano Mller <dev-zero@gentoo.org> wrote:

> > * 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.

Please fix all 'pkg fails tests' bugs in bugzilla first.

--
gcc-porting, by design, by neglect
treecleaner, for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
 
Old 03-16-2009, 10:54 PM
Ciaran McCreesh
 
Default EAPI 3 PMS Draft

On Mon, 16 Mar 2009 17:51:00 -0600
Ryan Hill <dirtyepic@gentoo.org> wrote:
> On Tue, 17 Mar 2009 00:22:36 +0100
> Tiziano Mller <dev-zero@gentoo.org> wrote:
> > > * 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.
>
> Please fix all 'pkg fails tests' bugs in bugzilla first.

The nice thing about doing it on an EAPI bump is that it's incremental.
As people move towards EAPI 3, they'll all get caught and fixed.

With the current situation, src_test is worthless because a failure
doesn't mean there's a problem worth investigating. But if EAPI 3
starts making src_test "run unless explicitly RESTRICTed or disabled",
any src_test failure in an EAPI 3 package will tell people something
requires attention.

--
Ciaran McCreesh
 
Old 03-16-2009, 11:05 PM
"Jorge Manuel B. S. Vicetto"
 
Default EAPI 3 PMS Draft

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ciaran McCreesh wrote:
> On Tue, 17 Mar 2009 00:26:36 +0100
> Tomáš Chvátal <scarabeus@gentoo.org> wrote:
>>> Why? It was an official EAPI agreed upon by the Gentoo KDE project.
>>> Having it there is helpful for package manager people, and removing
>>> it would just mean more work when features make their way into
>>> Portage. Besides, if you really don't want to see it, you can just
>>> make it all invisible with one easy switch.
>>>
>> Actualy now people expect kde team to manage support for kdebuild
>> too. So it is not such crazy request.
>
> There's a lot of kdebuild-1 stuff still out there that the Gentoo KDE
> team created, and that users used because it was the best option at
> the time. You can't pretend it never existed. And remember, a package
> manager can't correctly uninstall something unless it knows about the
> installed package's EAPI.
>
>>> We've been over all this before. Unless you have something new to
>>> add, kindly avoid wasting people's time.
>> And you are not wasting others time by flaming all around glep 54. I
>> dont mean i dont agree with the glep i just dont agree with your way
>> promoting it. And if you say i dont have to read all the long flame
>> around you dont have the right saying somebody else not to write his
>> ideas on this mailing list.
>
> There has yet to be a decent technical objection to kdebuild-1
> being in PMS. There has yet to be a decent technical objection to GLEP
> 54. Anyone going around objecting to either without bringing new
> material to the table is either trolling or hasn't done their homework.

Ciaran,

the point about kdebuild-1 and PMS was settled by the previous council
who decided that it wasn't and would never be part of the Gentoo PMS and
asked you to remove it from the document. Some people have argued about
removing that EAPI from your document, but in my view they're wasting
time as it simply is not part of the official Gentoo PMS currently.
About it being approved by the Gentoo KDE team, that's not entirely
true. Most of the members of the team at the time worked on it and opted
to use it, but there was never a vote to approve it officially. I have
no problem with the overlay still using it and will try to ensure that
we don't break it. However, like the members of the KDE team at the time
opted to use the kdebuild-1 EAPI, the current members have opted to use
EAPI-2 and don't support kdebuild-1 themselves.
As the only PM that ever supported kdebuild-1 is paludis, the backwards
compatibility issue is not as relevant as no one is asking you to drop
the kdebuild-1 support from paludis and portage and pkgcore can keep
ignoring those ebuilds.
I don't have a problem with the kdebuild-1 EAPI, but it should be clear
that it was never an official Gentoo EAPI. It should also be cleared
that although it was the chosen EAPI for the KDE team 18 months ago, it
is no longer used by the current team. There was a time for it and it
opened the road for some very useful features that have already been
delivered in EAPI-2 or that are being discussed for future EAPIs. As
such, I propose a different approach for this issue. I suggest we create
an Appendix with non-official EAPIs and non-approved proposals. That
way, kdebuild-1 and other EAPIs would be listed in the Appendix, so we
could have a list of features or proposed features, and it would also be
clear they're not official EAPIs.
What do you think?

- --
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / SPARC / KDE
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkm+6TMACgkQcAWygvVEyAIF6ACgkox34uc08L HpLjW+iSRmCGJe
9MQAn0g0AaOiq1C9pfRcfCTYhyhYb0+D
=g6se
-----END PGP SIGNATURE-----
 

Thread Tools




All times are GMT. The time now is 10:11 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org