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 bin
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 vo
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 an
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 t
On Thu, 9 Apr 2009 18:21:55 +0200
Patrick Lauer 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 tr
On Thu, 09 Apr 2009 19:20:39 +0300
Mart Raudsepp 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, correctnes
On Thursday 09 April 2009 16:37:55 Ciaran McCreesh wrote:
> On Thu, 09 Apr 2009 04:12:02 +0300
>
> Mart Raudsepp 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 enablin
On N, 2009-04-09 at 15:37 +0100, Ciaran McCreesh wrote:
> On Thu, 09 Apr 2009 04:12:02 +0300
> Mart Raudsepp 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 i
On Thu, 09 Apr 2009 04:12:02 +0300
Mart Raudsepp 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
On Tue, 2009-03-17 at 13:55 +, Ciaran McCreesh wrote:
> On Tue, 17 Mar 2009 10:50:17 +0300
> Peter Volkov 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 defini
On 16-03-2009 20:47:17 +, 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 fr
On Tue, 17 Mar 2009 16:11:48 +0100
Ulrich Mueller 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 intereste
> 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 nee
On Tue, 17 Mar 2009 09:57:16 +0100
Ulrich Mueller 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
On Tue, 17 Mar 2009 10:50:17 +0300
Peter Volkov 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
signature.asc
Description: PGP signature
On Tue, 17 Mar 2009 09:05:49 +0100
Ulrich Mueller 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* PR
> 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
(m
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 f
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
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 miss
> 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
В Пнд, 16/03/2009 в 20:47 +, 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
> 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
On Tue, Mar 17, 2009 at 6:16 AM, Thomas Anderson 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
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 removi
On Mon, 16 Mar 2009 23:05:07 -0100
"Jorge Manuel B. S. Vicetto" 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
> On Tue, 17 Mar 2009 00:26:36 +0100
> Tomáš Chvátal 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 m
On Tue, 17 Mar 2009 00:26:36 +0100
Tomáš Chvátal 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 re
Dne úterý 17 Březen 2009 00:20:11 Ciaran McCreesh napsal(a):
> On Mon, 16 Mar 2009 23:59:45 +0100
>
> Maciej Mrozowski 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, es
Thanks a lot for your work.
Am Montag, den 16.03.2009, 20:47 + 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 b
On Mon, 16 Mar 2009 23:59:45 +0100
Maciej Mrozowski 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
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
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
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 b
34 matches
Mail list logo
