[gentoo-dev] EAPI 3 PMS Draft

[gentoo-dev] EAPI 3 PMS Draft

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 3172 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI 3 PMS Draft

[Maciej Mrozowski]

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

Re: [gentoo-dev] EAPI 3 PMS Draft

[Rémi Cardona]

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.

Rémi

Re: [gentoo-dev] EAPI 3 PMS Draft

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 829 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI 3 PMS Draft

[Tiziano Müller]

[-- Attachment #1: Type: text/plain, Size: 4638 bytes --]


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


[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] EAPI 3 PMS Draft

[Tomáš Chvátal]

[-- Attachment #1: Type: text/plain, Size: 1324 bytes --]

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.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] EAPI 3 PMS Draft

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1918 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-dev] Re: EAPI 3 PMS Draft

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 587 bytes --]

On Tue, 17 Mar 2009 00:22:36 +0100
Tiziano Müller <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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: EAPI 3 PMS Draft

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 917 bytes --]

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 Müller <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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] EAPI 3 PMS Draft

[Jorge Manuel B. S. Vicetto]

-----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+6TMACgkQcAWygvVEyAIF6ACgkox34uc08LHpLjW+iSRmCGJe
9MQAn0g0AaOiq1C9pfRcfCTYhyhYb0+D
=g6se
-----END PGP SIGNATURE-----

Re: [gentoo-dev] EAPI 3 PMS Draft

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1935 bytes --]

On Mon, 16 Mar 2009 23:05:07 -0100
"Jorge Manuel B. S. Vicetto" <jmbsvicetto@gentoo.org> wrote:
> 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.

Hence the "remove kdebuild" switch you can turn on if you're looking to
use PMS for 'official' purposes rather than package manager development.

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

The Gentoo KDE team lead at the time approved it and recognised it as
official.

> 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 was officially approved by the Gentoo KDE team lead on behalf of his
team.

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

So? I'd hope people aren't using EAPI 0 for anything new now either.

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

It doesn't work. There's no sensible way of separating out technical
details of EAPIs into an appendix whilst keeping things readable. A
summary as an appendix with references to the detailed section does
work, and that's there already, as is a description of kdebuild-1's
status.

Also, this has nothing to do with EAPI 3. Please stop flogging this dead
horse so that the noise doesn't drown out what we're trying to get done
here.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] EAPI 3 PMS Draft

[Thomas Anderson]

On Mon, Mar 16, 2009 at 11:59:45PM +0100, Maciej Mrozowski wrote:
> 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.

While I'm sure there will be arguments for and against this, their merit
really does not matter. What matters is that this is completely offtopic
for the question of what should be in EAPI 3, and those feature's
specification. Please please do not associate the two as it'll just
prolong the acceptance of EAPI 3, and we all know we don't want that.

Regards,
Thomas
-- 
---------
Thomas Anderson
Gentoo Developer
/////////
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
---------

[gentoo-dev] Re: EAPI 3 PMS Draft

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1486 bytes --]

On Mon, 16 Mar 2009 23:54:02 +0000
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> 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 Müller <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.

Actually, that's a very good point.

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

Whether it's enabled for EAPI 3 or not, I'd at least like to see 'test'
added to FEATURES in targets/developer/make.defaults now.  That should
(hopefully) raise the visibility somewhat.


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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] EAPI 3 PMS Draft

[Nirbheek Chauhan]

On Tue, Mar 17, 2009 at 6:16 AM, Thomas Anderson <gentoofan23@gentoo.org> wrote:
> While I'm sure there will be arguments for and against this, their merit
> really does not matter. What matters is that this is completely offtopic
> for the question of what should be in EAPI 3, and those feature's
> specification. Please please do not associate the two as it'll just
> prolong the acceptance of EAPI 3, and we all know we don't want that.
>

++ discussions about this are best left for other threads, and (all
the better) other times.

-- 
~Nirbheek Chauhan

Re: [gentoo-dev] Re: EAPI 3 PMS Draft

[Luca Barbato]

Ryan Hill wrote:
> On Tue, 17 Mar 2009 00:22:36 +0100
> Tiziano Müller <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.
> 

And the fact some testsuites in system and commonly used libs take from 
10x to 100x the buildtime to run.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

Re: [gentoo-dev] EAPI 3 PMS Draft

[Ulrich Mueller]

>>>>> On Tue, 17 Mar 2009, Tiziano Müller wrote:

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

Sorry, seems that I've missed the discussion on this one.

There is no 'cd "${S}"' command in the default functions. It's not
needed since they already start with S as their initial working
directory. If S doesn't point to an existing directory, WORKDIR is
used instead.

I hope you don't propose to remove this useful fallback behaviour in
general?

Ulrich

Re: [gentoo-dev] EAPI 3 PMS Draft

[Peter Volkov]

[-- Attachment #1: Type: text/plain, Size: 703 bytes --]

В Пнд, 16/03/2009 в 20:47 +0000, Ciaran McCreesh пишет:
> * Am I to take it src_test is to remain in its current worthless state?

Is it possible in EAPI 3 make src_test failures not fatal? Something
like make die() non fatal inside src_test. Package manager if it sees
die() inside src_test should remember this failure and warn people at
the end of merge that tests failed. It's wise to preserve output of
failed tests somewhere and may be introduce with some
FEATURES=tests-keepwork.

Probably this is not best implementation, but it describes idea well. If
failures are non fatal I don't object to having src_test enabled by
default and I'll all for this even.

-- 
Peter.

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI 3 PMS Draft

[Ulrich Mueller]

>>>>> On Tue, 17 Mar 2009, Peter Volkov wrote:

> Probably this is not best implementation, but it describes idea
> well. If failures are non fatal I don't object to having src_test
> enabled by default and I'll all for this even.

[Replying to a random message in this thread.]

Has anyone already noted that for some packages (especially in sci-*)
tests just take ages, namely a multiple of the compile time?

If we are to enable tests for all users by default, we need some way
to deal with this.

Ulrich

Re: [gentoo-dev] EAPI 3 PMS Draft

[Tiziano Müller]

[-- Attachment #1: Type: text/plain, Size: 751 bytes --]

Am Dienstag, den 17.03.2009, 07:47 +0100 schrieb Ulrich Mueller:
> >>>>> On Tue, 17 Mar 2009, Tiziano Müller wrote:
> 
> > 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}.
> 
> Sorry, seems that I've missed the discussion on this one.
> 
> There is no 'cd "${S}"' command in the default functions. It's not
> needed since they already start with S as their initial working
> directory. If S doesn't point to an existing directory, WORKDIR is
> used instead.
> 
> I hope you don't propose to remove this useful fallback behaviour in
> general?

Yes I do since I don't see anything useful in it. But I'm ready to be
taught otherwise.



[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] EAPI 3 PMS Draft

[Tiziano Müller]

[-- Attachment #1: Type: text/plain, Size: 855 bytes --]

Am Dienstag, den 17.03.2009, 09:05 +0100 schrieb Ulrich Mueller:
> >>>>> On Tue, 17 Mar 2009, Peter Volkov wrote:
> 
> > Probably this is not best implementation, but it describes idea
> > well. If failures are non fatal I don't object to having src_test
> > enabled by default and I'll all for this even.
> 
> [Replying to a random message in this thread.]
> 
> Has anyone already noted that for some packages (especially in sci-*)
> tests just take ages, namely a multiple of the compile time?
> 
> If we are to enable tests for all users by default, we need some way
> to deal with this.

Definitely. Not only sci-*, but also dev-libs/boost (for example) takes
more than a day on a fast machine while I can't even fail src_test if
some tests fail because the tests are sometimes really sensitive to some
gcc/glibc/arch/whatever.



[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] EAPI 3 PMS Draft

[Tiziano Müller]

[-- Attachment #1: Type: text/plain, Size: 491 bytes --]

Am Dienstag, den 17.03.2009, 00:22 +0100 schrieb Tiziano Müller:
> 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.

Ok, feature descriptions are pretty much complete. Please send
patches/comments if something is unclear or completely wrong.


[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] EAPI 3 PMS Draft

[Ulrich Mueller]

>>>>> On Tue, 17 Mar 2009, Tiziano Müller wrote:

>> I hope you don't propose to remove this useful fallback behaviour
>> in general?

> Yes I do since I don't see anything useful in it. But I'm ready to
> be taught otherwise.

There are dozens of packages in app-emacs making use of this feature
(most of them from before my time, so don't blame me ;-) ). Typically
their source is a single compressed lisp file and everything takes
place in WORKDIR. S is not needed because of the fallback.

Or has the fallback behaviour caused any problems elsewhere?

Ulrich

Re: [gentoo-dev] EAPI 3 PMS Draft

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 411 bytes --]

On Tue, 17 Mar 2009 09:05:49 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:
> Has anyone already noted that for some packages (especially in sci-*)
> tests just take ages, namely a multiple of the compile time?
> 
> If we are to enable tests for all users by default, we need some way
> to deal with this.

*shrug* PROPERTIES="slow-tests". Of course, then people will abuse it...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI 3 PMS Draft

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 263 bytes --]

On Tue, 17 Mar 2009 10:50:17 +0300
Peter Volkov <pva@gentoo.org> wrote:
> If failures are non fatal I don't object to having src_test enabled by
> default and I'll all for this even.

...and src_test becomes utterly worthless again.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI 3 PMS Draft

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 901 bytes --]

On Tue, 17 Mar 2009 09:57:16 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:
> There are dozens of packages in app-emacs making use of this feature
> (most of them from before my time, so don't blame me ;-) ). Typically
> their source is a single compressed lisp file and everything takes
> place in WORKDIR. S is not needed because of the fallback.

S="${WORKDIR}" in global scope then.

> Or has the fallback behaviour caused any problems elsewhere?

The fallback causes problems when there's a default src_install. Having
a default src_install means an ebuild with a dodgy tarball but no
functions is likely to make it all the way through past the install;
previously it would die on the custom-written src_install.

Note that the wording is such that this will only matter for ebuilds
that install things. Blank ebuilds that install nothing will still work.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI 3 PMS Draft

[Ulrich Mueller]

>>>>> On Tue, 17 Mar 2009, Ciaran McCreesh wrote:

>> There are dozens of packages in app-emacs making use of this
>> feature (most of them from before my time, so don't blame me ;-) ).
>> Typically their source is a single compressed lisp file and
>> everything takes place in WORKDIR. S is not needed because of the
>> fallback.

> S="${WORKDIR}" in global scope then.

Yes, I don't doubt that the problem can be solved. ;-) Maybe we can
assign S in src_unpack in one of our eclasses.

> The fallback causes problems when there's a default src_install.
> Having a default src_install means an ebuild with a dodgy tarball
> but no functions is likely to make it all the way through past the
> install; previously it would die on the custom-written src_install.

I see.

> Note that the wording is such that this will only matter for ebuilds
> that install things. Blank ebuilds that install nothing will still
> work.

How can you know that before src_install?

Ulrich

Re: [gentoo-dev] EAPI 3 PMS Draft

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 520 bytes --]

On Tue, 17 Mar 2009 16:11:48 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:
> > Note that the wording is such that this will only matter for ebuilds
> > that install things. Blank ebuilds that install nothing will still
> > work.
> 
> How can you know that before src_install?

DEFINED_PHASES + A. If you're interested in the gory details, either
wait until I push the next PMS draft or have a look at [1].

[1]: http://lists.exherbo.org/pipermail/exherbo-dev/2009-February/000396.html

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-dev] Re: EAPI 3 PMS Draft

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 489 bytes --]

On Mon, 16 Mar 2009 20:47:17 +0000
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
>     http://github.com/ciaranm/pms/tree/eapi-3

Updated draft:

* S to WORKDIR fallback conditional for EAPI 3
* EAPI 3 has unpack --if-compressed, new src_unpack
* Formatting: -- should be -{}- for econf things
* RDEPEND=DEPEND gone in EAPI 3
* EAPI 3 has doexample.
* REPLACING_VERSIONS and REPLACED_BY_VERSION in EAPI 3
* EAPI 3 has nonfatal, utilities die

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI 3 PMS Draft

[Fabian Groffen]

On 16-03-2009 20:47:17 +0000, Ciaran McCreesh wrote:
> 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

I would like to request the following to be included in EAPI 3, as
preparation for more Prefix friendly ebuilds compatible with gentoo-x86:

- The variable EPREFIX to be set in all phases, and at all times.
  Because this is a preparation stage, EPREFIX is just set and
  intialised to the empty string.
- The variable ED, available in src_install, pkg_preinst and
  pkg_postinst, and set to ${D}${EPREFIX}.
- The variable EROOT, available in pkg_*[1], set to ${ROOT}${EPREFIX}.


[1] this is copied from PMS, Table 11.1, in general, EROOT needs to be
available where currently ROOT is.


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-dev] EAPI 3 PMS Draft

[Mart Raudsepp]

[-- Attachment #1: Type: text/plain, Size: 1420 bytes --]

On Tue, 2009-03-17 at 13:55 +0000, Ciaran McCreesh wrote:
> On Tue, 17 Mar 2009 10:50:17 +0300
> Peter Volkov <pva@gentoo.org> wrote:
> > If failures are non fatal I don't object to having src_test enabled by
> > default and I'll all for this even.
> 
> ...and src_test becomes utterly worthless again.

Your definition of worthless doesn't match the one in my vocabulary,
because it is very much worth it when many developers have FEATURES=test
and routinely make sure the packages they use pass the test or file a
bug.

It is quite irresponsible to enable that by default for the FULL user
base, given the state of the tree in regards to it, many upstreams
stance on tests and their failures, and the (very) considerable extra
time it takes to run them while it's already slower in relation to
binary distributions.

Enabling tests by default feels like driving users away, because all of
a sudden their upgrades taken even more time (possibly unexplained to
them, as an EAPI bump in an ebuild introducing it is not visible to
them), and they'd just say to hell with it and go to a binary
distribution that runs the tests for maintainers only, as we should.

Yet we have the _choice_ to take that extra time and double-check on
maintainers if they really did their job right.


-- 
Mart Raudsepp
Gentoo Developer
Mail: leio@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI 3 PMS Draft

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 749 bytes --]

On Thu, 09 Apr 2009 04:12:02 +0300
Mart Raudsepp <leio@gentoo.org> wrote:
> It is quite irresponsible to enable that by default for the FULL user
> base, given the state of the tree in regards to it

Which is why we are not talking about enabling it for the tree. We are
talking about enabling it for a subset of the tree that's guaranteed to
have been tested by it.

> many upstreams stance on tests and their failures

So for those packages, RESTRICT tests like you should be doing anyway.

> and the (very) considerable extra time it takes to run them while
> it's already slower in relation to binary distributions.

PROPERTIES="slow-tests" then.

We've been over all of this several times previously.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI 3 PMS Draft

[Mart Raudsepp]

[-- Attachment #1: Type: text/plain, Size: 1495 bytes --]

On N, 2009-04-09 at 15:37 +0100, Ciaran McCreesh wrote:
> On Thu, 09 Apr 2009 04:12:02 +0300
> Mart Raudsepp <leio@gentoo.org> wrote:
> > It is quite irresponsible to enable that by default for the FULL user
> > base, given the state of the tree in regards to it
> 
> Which is why we are not talking about enabling it for the tree. We are
> talking about enabling it for a subset of the tree that's guaranteed to
> have been tested by it.
> 
> > many upstreams stance on tests and their failures
> 
> So for those packages, RESTRICT tests like you should be doing anyway.
> 
> > and the (very) considerable extra time it takes to run them while
> > it's already slower in relation to binary distributions.
> 
> PROPERTIES="slow-tests" then.

Every single test on any package is going to be done slower than not
running tests.
This PROPERTIES proposal has no relevance to the argument of why it is
an extremely bad idea to enable it by default.

All developers should enable it (a QA enforcement), but users by default
- no, NO.
There is more to a distribution than technical considerations.

> We've been over all of this several times previously.

Yes, and by my understanding this will not be happening anytime soon, if
ever, so I can repeat all my sound objections to it whenever you bring
it up again in the more distant future, thank you.


-- 
Mart Raudsepp
Gentoo Developer
Mail: leio@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI 3 PMS Draft

[Patrick Lauer]

On Thursday 09 April 2009 16:37:55 Ciaran McCreesh wrote:
> On Thu, 09 Apr 2009 04:12:02 +0300
>
> Mart Raudsepp <leio@gentoo.org> wrote:
> > It is quite irresponsible to enable that by default for the FULL user
> > base, given the state of the tree in regards to it
>
> Which is why we are not talking about enabling it for the tree. We are
> talking about enabling it for a subset of the tree that's guaranteed to
> have been tested by it.

So you propose to make a new EAPI that about 2.5% of the tree can use?

> > and the (very) considerable extra time it takes to run them while
> > it's already slower in relation to binary distributions.
>
> PROPERTIES="slow-tests" then.
>
> We've been over all of this several times previously.

And it is still the same stupid idea. We have FEATURES="test" for those who 
care, and if you look at the amount of bugs that causes already I see no sane 
way to make it default.
Why would you enable it by default just to disable it by default in those 
packages where it is the most important?

Tell you what. Provide patches for all open test failure bugs and provide a 
list of all packages where tests are slow (for certain values of slow we'd 
have to agree on) and you can resume pushing your toy ideas. 

Have fun,

Patrick

Re: [gentoo-dev] EAPI 3 PMS Draft

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1195 bytes --]

On Thu, 09 Apr 2009 19:20:39 +0300
Mart Raudsepp <leio@gentoo.org> wrote:
> Every single test on any package is going to be done slower than not
> running tests.

So? If speed were important, people would use a binary distribution,
or just drop to -O1. But given the massive variability of Gentoo
systems, correctness is a far bigger worry.

> This PROPERTIES proposal has no relevance to the argument of why it is
> an extremely bad idea to enable it by default.

Sure it does. It means that for any package where there's a really
large slow-down, users will only run the tests if they want to.

> > We've been over all of this several times previously.
> 
> Yes, and by my understanding this will not be happening anytime soon,
> if ever, so I can repeat all my sound objections to it whenever you
> bring it up again in the more distant future, thank you.

Unfortunately, it looks like this proposal's one of those things that
some people will hate for ideological reasons no matter what. I just
hope there're enough people on the Council for whom QA and user systems
not breaking is sufficiently important that they'll vote in favour of
it.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI 3 PMS Draft

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 2167 bytes --]

On Thu, 9 Apr 2009 18:21:55 +0200
Patrick Lauer <patrick@gentoo.org> wrote:
> > Which is why we are not talking about enabling it for the tree. We
> > are talking about enabling it for a subset of the tree that's
> > guaranteed to have been tested by it.
> 
> So you propose to make a new EAPI that about 2.5% of the tree can use?

Of course not. No-one's stupid enough to think that's even remotely
true, so please don't say things like that.

Most packages that have tests have working tests. For those that don't,
the tests have to be restricted. All this proposal does is ensures that
that happens in a progressive, incremental and safe way.

Had src_test been introduced after EAPIs came along, this would already
have happened.

> And it is still the same stupid idea. We have FEATURES="test" for
> those who care, and if you look at the amount of bugs that causes
> already I see no sane way to make it default.

It causes lots of bugs because it's not the default.

> Why would you enable it by default just to disable it by default in
> those packages where it is the most important?

If packages are failing tests, either it's a legitimate reason, in
which case it needs to be fixed, or it's not, in which case it needs to
be restricted. The problem is, currently there's no way for users to
know which is which. With an EAPI mandated src_test, users will know
that any failure that gets to them is legitimate.

> Tell you what. Provide patches for all open test failure bugs and
> provide a list of all packages where tests are slow (for certain
> values of slow we'd have to agree on) and you can resume pushing your
> toy ideas. 

There's no need to. That's the beauty of this proposal. As packages are
moved to EAPI 3, any package with broken tests can, at the maintainer's
choice, either get RESTRICT=test (which they should have been given
already) or get fixed tests.

This is no more work for maintainers. All it does is makes sure they do
something they should be doing already, and in the process makes things
much safer for users.

Again, this has all already been covered.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI 3 PMS Draft

[Richard Freeman]

Ciaran McCreesh wrote:
> 
> Most packages that have tests have working tests. For those that don't,
> the tests have to be restricted. All this proposal does is ensures that
> that happens in a progressive, incremental and safe way.
> 

I agree with this point - failing tests are more the exception than the 
rule.

Looking at my system the only packages I'm skipping tests for are:
openldap|parted|orbit|samba|kpilot|nautilus|libksieve|karm|libbonoboui|gnome-vfs|pkgconfig|pam|coreutils|pan|mono|glibc|gettext|curl

Some of those might be fixed now.

> If packages are failing tests, either it's a legitimate reason, in
> which case it needs to be fixed, or it's not, in which case it needs to
> be restricted. The problem is, currently there's no way for users to
> know which is which. With an EAPI mandated src_test, users will know
> that any failure that gets to them is legitimate.

Hence my having the list posted above (which is just the ones I use that 
  I've found problems with).

I also would like to say that the "slow-test" compromise sounds like a 
good idea.

A fast-running automated test routine is a good sanity check to show 
that nothing went wrong during the build.  Maybe the user has some odd 
version of a dependency that no developer checked with the new package. 
  Arch testers can't test every combination of dependencies, 
configurations, use-flags, etc.

I would think that this might even cut down on user-reported issues. 
Better to find out that a package has a problem BEFORE it is actually 
installed.

If a user is going to spend 10 minutes building a bunch of packages 
spending another 30-60 seconds on some basic tests doesn't sound 
unreasonable.  We could also make it easy for users to disable testing 
entirely if they want to live dangerously.

Re: [gentoo-dev] EAPI 3 PMS Draft

[Tiziano Müller]

[-- Attachment #1: Type: text/plain, Size: 2042 bytes --]

Am Donnerstag, den 09.04.2009, 13:13 -0400 schrieb Richard Freeman:
> Ciaran McCreesh wrote:
> > 
> > Most packages that have tests have working tests. For those that don't,
> > the tests have to be restricted. All this proposal does is ensures that
> > that happens in a progressive, incremental and safe way.
> > 
> 
> I agree with this point - failing tests are more the exception than the 
> rule.
> 
> Looking at my system the only packages I'm skipping tests for are:
> openldap|parted|orbit|samba|kpilot|nautilus|libksieve|karm|libbonoboui|gnome-vfs|pkgconfig|pam|coreutils|pan|mono|glibc|gettext|curl
No need to skip samba, there are no tests anymore.

> 
> Some of those might be fixed now.
> 
> > If packages are failing tests, either it's a legitimate reason, in
> > which case it needs to be fixed, or it's not, in which case it needs to
> > be restricted. The problem is, currently there's no way for users to
> > know which is which. With an EAPI mandated src_test, users will know
> > that any failure that gets to them is legitimate.
> 
> Hence my having the list posted above (which is just the ones I use that 
>   I've found problems with).
> 
> I also would like to say that the "slow-test" compromise sounds like a 
> good idea.
> 
> A fast-running automated test routine is a good sanity check to show 
> that nothing went wrong during the build.  Maybe the user has some odd 
> version of a dependency that no developer checked with the new package. 
>   Arch testers can't test every combination of dependencies, 
> configurations, use-flags, etc.
> 
> I would think that this might even cut down on user-reported issues. 
> Better to find out that a package has a problem BEFORE it is actually 
> installed.
> 
> If a user is going to spend 10 minutes building a bunch of packages 
> spending another 30-60 seconds on some basic tests doesn't sound 
> unreasonable.  We could also make it easy for users to disable testing 
> entirely if they want to live dangerously.
> 

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: EAPI 3 PMS Draft

[Christian Faulhammer]

[-- Attachment #1: Type: text/plain, Size: 1259 bytes --]

Hi,

Ciaran McCreesh <ciaran.mccreesh@googlemail.com>:

> On Thu, 09 Apr 2009 04:12:02 +0300
> Mart Raudsepp <leio@gentoo.org> wrote:
> > It is quite irresponsible to enable that by default for the FULL
> > user base, given the state of the tree in regards to it
> 
> Which is why we are not talking about enabling it for the tree. We are
> talking about enabling it for a subset of the tree that's guaranteed
> to have been tested by it.

 Some years ago as a Gentoo beginner I read the documentation of
FEATURES and enabled "test", because it sounded useful.  After one week
I disabled it again as merges took too long and some failures occured.
Read: As a normal user I don't want src_test for every single package
that is installed on my system for whatever reason.  FEATURES=test is
perfect for people who help maintain the distribution or want to test a
specific subset of packages they heavily rely on.
 So imposing that penalty on everyone even the unexperienced will
likely confuse some people.  Go to the forums or the support mailing
list to see what I mean.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: EAPI 3 PMS Draft

[James Rowe]

[-- Attachment #1: Type: text/plain, Size: 1341 bytes --]

* Christian Faulhammer (fauli@gentoo.org) wrote:
>  Some years ago as a Gentoo beginner I read the documentation of
> FEATURES and enabled "test", because it sounded useful.  After one week
> I disabled it again as merges took too long and some failures occured.
> Read: As a normal user I don't want src_test for every single package
> that is installed on my system for whatever reason.  FEATURES=test is
> perfect for people who help maintain the distribution or want to test a
> specific subset of packages they heavily rely on.

  I'm just a user and I run with FEATURES=test, and have done since at
least March 2005[1].  I've definitely toyed with disabling it myself,
but only because developers aren't using it, which means I catch bugs[2]
that would have never existed if the developer had `test' enabled.

>  So imposing that penalty on everyone even the unexperienced will
> likely confuse some people.  Go to the forums or the support mailing
> list to see what I mean.

  Package tests will have been run a -- possibly large -- number of
times when users see them if they are rolled in to the EAPI bump.  This
isn't like the current situation of enabling tests and hoping somebody
has run them during testing.

Thanks,

James
  1. http://bugs.gentoo.org/show_bug.cgi?id=85901
  2. http://bugs.gentoo.org/show_bug.cgi?id=138415


[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Re: EAPI 3 PMS Draft

[Marijn Schouten (hkBst)]

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

James Rowe wrote:
> * Christian Faulhammer (fauli@gentoo.org) wrote:
>>  Some years ago as a Gentoo beginner I read the documentation of
>> FEATURES and enabled "test", because it sounded useful.  After one week
>> I disabled it again as merges took too long and some failures occured.
>> Read: As a normal user I don't want src_test for every single package
>> that is installed on my system for whatever reason.  FEATURES=test is
>> perfect for people who help maintain the distribution or want to test a
>> specific subset of packages they heavily rely on.
> 
>   I'm just a user and I run with FEATURES=test, and have done since at
> least March 2005[1].  I've definitely toyed with disabling it myself,
> but only because developers aren't using it, which means I catch bugs[2]
> that would have never existed if the developer had `test' enabled.

Just because we find failing tests doesn't mean we have time (or inclination) to
investigate and fix them.

>>  So imposing that penalty on everyone even the unexperienced will
>> likely confuse some people.  Go to the forums or the support mailing
>> list to see what I mean.
> 
>   Package tests will have been run a -- possibly large -- number of
> times when users see them if they are rolled in to the EAPI bump.  This
> isn't like the current situation of enabling tests and hoping somebody
> has run them during testing.

You conclusion that developers do not run tests is based on nothing. Using
RESTRICT=test is not a fix and just hides the problem, so it is not unthinkable
that packages with failing tests get to stable.

Marijn

- --
If you cannot read my mind, then listen to what I say.

Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
<http://www.gentoo.org/proj/en/lisp/>, #gentoo-{lisp,ml} on FreeNode
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkngd5UACgkQp/VmCx0OL2yxyQCfeV2wrXCd3M2nrhGYRnQtBh2u
O24AoJzvNKtnov0yjpQdtHao7fXcFPGx
=Unhp
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: EAPI 3 PMS Draft

[James Rowe]

[-- Attachment #1: Type: text/plain, Size: 905 bytes --]

* Marijn Schouten (hkBst) (hkBst@gentoo.org) wrote:
> James Rowe wrote:
> >   Package tests will have been run a -- possibly large -- number of
> > times when users see them if they are rolled in to the EAPI bump.  This
> > isn't like the current situation of enabling tests and hoping somebody
> > has run them during testing.
> 
> You conclusion that developers do not run tests is based on nothing. Using
> RESTRICT=test is not a fix and just hides the problem, so it is not unthinkable
> that packages with failing tests get to stable.

  Well, I didn't suggest using RESTRICT=test so I'm not sure
I understand your point.  That being said while it definitely isn't
a good result that packages with failing tests have RESTRICT=test set
those packages aren't going to cause test failures for stable users
anyway.

Thanks,

James
  1. http://bugs.gentoo.org/show_bug.cgi?id=85901


[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI 3 PMS Draft

[Alistair Bush]

Ciaran McCreesh wrote:
> 
> Unfortunately, it looks like this proposal's one of those things that
> some people will hate for ideological reasons no matter what. I just
> hope there're enough people on the Council for whom QA and user systems
> not breaking is sufficiently important that they'll vote in favour of
> it.
> 

While I support enabling test by default I'm about to do a "foot in
mouth" moment and suggest something that is far too over complicated

This is a compromise between those that want tests by default and those
who don't and has these simple rules

1) Tests are enabled by default for ~arch ebuilds.
2) Tests are _not_ enabled by default for stable ebuilds.

~arch users will therefore have to explicitly disable tests and run the
risks associated with that.  My guess is that arch users are also the
ones more likely to have CFLAGS or LDFLAGS that are significantly
different from the defaults hopefully enabling tests will catch all the
issues we know that are going to have.

arch users will have to explicitly enable tests,  but hopefully by the
time a package has been marked stable it has had its unit tests ( oh im
pointing that foot in mouth again ) run enough times to verify its
correctness.

Re: [gentoo-dev] EAPI 3 PMS Draft

[Alistair Bush]

Mart Raudsepp wrote:
> Enabling tests by default feels like driving users away, because all of
> a sudden their upgrades taken even more time (possibly unexplained to
> them, as an EAPI bump in an ebuild introducing it is not visible to
> them), and they'd just say to hell with it and go to a binary
> distribution that runs the tests for maintainers only, as we should.
> 
> Yet we have the _choice_ to take that extra time and double-check on
> maintainers if they really did their job right.

I agree that before EAPI 3 hits the tree we need to do some extensive
pr.  There should be a howto on the changes and what they mean to users,
the benefits and costs etc.  How to enable/disable those changes etc etc.

But in reality all we need is 1 document, links and news items (yes more
than 1 preferably) posted on our homepage, forums, mailing lists.  Hell
even within ebuilds if it comes to that.  If after all that a user still
hasn't figured out that they need to go read that document are we really
in a position where we can do anything else.

[gentoo-dev] Re: EAPI 3 PMS Draft

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 605 bytes --]

On Thu, 09 Apr 2009 19:20:39 +0300
Mart Raudsepp <leio@gentoo.org> wrote:

> All developers should enable it (a QA enforcement), but users by default
> - no, NO.
> There is more to a distribution than technical considerations.

Yes, please, and can we do it now?  I am frankly sick of failing testsuites
and would really like everyone else to be sick of them too.


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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: EAPI 3 PMS Draft

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 403 bytes --]

On 20:47 Mon 16 Mar     , Ryan Hill wrote:
> Whether it's enabled for EAPI 3 or not, I'd at least like to see 'test'
> added to FEATURES in targets/developer/make.defaults now.  That should
> (hopefully) raise the visibility somewhat.

I'm all for enabling it in the dev profile by default.

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: EAPI 3 PMS Draft

[Nirbheek Chauhan]

On Thu, Apr 23, 2009 at 11:02 AM, Donnie Berkholz <dberkholz@gentoo.org> wrote:
> On 20:47 Mon 16 Mar     , Ryan Hill wrote:
>> Whether it's enabled for EAPI 3 or not, I'd at least like to see 'test'
>> added to FEATURES in targets/developer/make.defaults now.  That should
>> (hopefully) raise the visibility somewhat.
>
> I'm all for enabling it in the dev profile by default.
>

There are some packages[1] for which installing with --enable-tests is
considered a "security risk" by upstream. What about packages such as
this?


1. Well, okay, atleast one I know of -- sys-apps/dbus
-- 
~Nirbheek Chauhan