В Чтв, 09/04/2009 в 15:32 +0100, Ciaran McCreesh пишет:
> Please provide a list of packages that use custom configure scripts,
> that currently work with econf (including all the weird things it
> already passes), that would break with this change and whose ebuilds
> are using econf. I have yet to
On Thu, 09 Apr 2009 13:44:55 +0300
Mart Raudsepp wrote:
> But the metadata cache isn't per-EAPI in the sense of multiple
> metadata caches, one for each EAPI. There might be per-EAPI metadata
> cache items though.
The cache format is per-EAPI, with a degree of overlap.
> I don't think I want to
On Thu, 09 Apr 2009 04:51:06 +0300
Mart Raudsepp wrote:
> doins support for symlinks
> ==
>
> Lacking information. Need to see if the PMS draft has anything about
> it. The bug and summaries just talk about the support, but no
> details. Would it be an argument to doins?
On N, 2009-04-09 at 10:37 +0200, Tiziano Müller wrote:
> > properties must be cached properly
> > ==
> >
> > No opinion, up to the package manager developers.
> > Don't see offhand why it should be an EAPI item at all. Feels like
> an
> > implementation detail.
>
>
Am Donnerstag, den 09.04.2009, 04:51 +0300 schrieb Mart Raudsepp:
> Hello,
>
> On Sun, 2009-03-08 at 08:49 +0100, Tiziano Müller wrote:
>
> > With eapis 1 and 2 we introduced nice features but also a couple of
> > new
> > problems. One of them are the use dependencies when the package you
> > dep
On Thu, 2009-04-09 at 04:51 +0300, Mart Raudsepp wrote:
> --disable-dependency-tracking:
> ==
>
> possible breakage of (custom) configure scripts that don't accept
> unknown arguments. Would be nice to pass that for most packages, but
> doing it always with econf seems
On Thu, 2009-04-09 at 04:51 +0300, Mart Raudsepp wrote:
>
> In separate threads:
..
> * dohard being deprecated
Actually bug #235642 has been fixed by now, and therefore this seems
simple enough.
The main reasoning for deprecation (and banning) of dohard() was that
bug as far as I understood, a
Hello,
On Sun, 2009-03-08 at 08:49 +0100, Tiziano Müller wrote:
> With eapis 1 and 2 we introduced nice features but also a couple of
> new
> problems. One of them are the use dependencies when the package you
> depend on doesn't have the use flag anymore (see [1] for an example).
>
> So I think
Am Freitag, den 13.03.2009, 20:11 + schrieb Ciaran McCreesh:
> On Sun, 08 Mar 2009 08:49:16 +0100
> Tiziano Müller wrote:
> > So I think it's time for a short eapi bump with some distinct
> > improvements:
>
> Some more small candidates to discuss:
>
> * How would people feel about killing o
On Sun, 08 Mar 2009 08:49:16 +0100
Tiziano Müller wrote:
> So I think it's time for a short eapi bump with some distinct
> improvements:
Some more small candidates to discuss:
* How would people feel about killing off automagic RDEPEND=DEPEND
behaviour?
* Officially kill off AA. It's not usef
On Fri, 13 Mar 2009 00:05:54 +0100
Maciej Mrozowski wrote:
> No idea whether it's "fast" idea, but:
>
> - USE flags aliases
Aliases for anything aren't fast or easy.
The big problem is this: the interactions between installed packages and
the main repository, and between the main repository and
No idea whether it's "fast" idea, but:
- USE flags aliases
This could solve problems with USE flag name changes and breaking dependency
tree because of it.
Placed, let's say in profiles/{use.aliases,use.local.aliases}
example - use.aliases: (no idea whether global aliases are really needed)
#
On Thu, 12 Mar 2009 11:43:58 -0700
Donnie Berkholz wrote:
> > Currently, if a package does an explicit 'unpack foo.bar',
> > where .bar is an unsupported archive format, unpack just does
> > nothing. This isn't a good default behaviour; if a package really
> > wants something to be ignored silentl
On 22:53 Mon 09 Mar , Ciaran McCreesh wrote:
> On Mon, 9 Mar 2009 15:39:41 -0700
> Donnie Berkholz wrote:
> > > * Calling unpack on an unrecognised extension should be fatal,
> > > unless --if-compressed is specified. The default src_unpack needs
> > > to use this.
> >
> > Why?
>
> Currently
On Mon, Mar 9, 2009 at 3:26 PM, Ciaran McCreesh <
ciaran.mccre...@googlemail.com> wrote:
> On Sun, 08 Mar 2009 08:49:16 +0100
> Tiziano Müller wrote:
> > http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ
>
> Here're some more easy ones.
>
> First up, un-optionaling some optional thin
On Monday March 09 Ciaran McCreesh wrote:
>
> * src_test run unless RESTRICTed or explicitly disabled by the user
> (bug 184812)
Yes, and I would go even further: keep src_test for unit tests and
some kind of pkg_posttest for either a routine to test the package
once installed or an elog test rec
On Sun, 08 Mar 2009 08:49:16 +0100
Tiziano Müller wrote:
> With eapis 1 and 2 we introduced nice features but also a couple of
> new problems. One of them are the use dependencies when the package
> you depend on doesn't have the use flag anymore (see [1] for an
> example).
Here's another one to
On Tue, 10 Mar 2009 10:08:06 +0100
Michael Haubenwallner wrote:
> Whats wrong with 'set -e' and doing '|| true' behind?
Waaay too many false positives.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Mon, 2009-03-09 at 15:39 -0700, Donnie Berkholz wrote:
> > * Utility commands, even the ones that aren't functions, should die. To
> > get a non-die version, prefix the command with nonfatal (e.g.
> > 'nonfatal dodoc README', which just returns non-zero on failure
> > rather than splattin
On Mon, 09 Mar 2009 17:38:51 -0500
Jeremy Olexa wrote:
> Should the next EAPI (as proposed) be a major "release" in terms of
> naming?
We don't use major.minor numbers for EAPI or have a concept like that.
It's too much mess.
> And should it really be adding features?
Well... So far as I can s
On Mon, 9 Mar 2009 15:39:41 -0700
Donnie Berkholz wrote:
> > * Calling unpack on an unrecognised extension should be fatal,
> > unless --if-compressed is specified. The default src_unpack needs
> > to use this.
>
> Why?
Currently, if a package does an explicit 'unpack foo.bar', where .bar is
an
Tiziano � wrote:
Hi everyone
With eapis 1 and 2 we introduced nice features but also a couple of new
problems. One of them are the use dependencies when the package you
depend on doesn't have the use flag anymore (see [1] for an example).
So I think it's time for a short eapi bump with some dis
On Mon, 9 Mar 2009 20:26:24 +
Ciaran McCreesh wrote:
> * src_test run unless RESTRICTed or explicitly disabled by the user
> (bug 184812)
This one is not uncontroversial and will not go in a 'quick' EAPI I
think.
/loki_val
On 20:26 Mon 09 Mar , Ciaran McCreesh wrote:
> On Sun, 08 Mar 2009 08:49:16 +0100
> Tiziano Müller wrote:
> > http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ
>
> Here're some more easy ones.
This list sounds mostly good to me.
> * Limit values in $USE to ones in $IUSE (bug 17
On Mon, 09 Mar 2009 14:28:48 -0700
Zac Medico wrote:
> > If we must do that... Can we get something in profiles a bit like
> > this:
> >
> > USE_EXPAND_IMPLICIT="USERLAND KERNEL ELIBC ARCH"
> > USE_EXPAND_UNPREFIXED="ARCH"
> > USE_EXPAND_VALUES_USERLAND="GNU freebsd"
> > USE_EXPAN
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
> On Mon, 09 Mar 2009 13:56:19 -0700
> Zac Medico wrote:
>> Ciaran McCreesh wrote:
>>> * Limit values in $USE to ones in $IUSE (bug 176467). The existing
>>> behaviour's majorly annoying; time for the package manager to
>>> st
On Mon, 09 Mar 2009 13:56:19 -0700
Zac Medico wrote:
> Ciaran McCreesh wrote:
> > * Limit values in $USE to ones in $IUSE (bug 176467). The existing
> > behaviour's majorly annoying; time for the package manager to
> > start enforcing things strictly.
>
> My impression is that most ebuild devel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
> * Limit values in $USE to ones in $IUSE (bug 176467). The existing
> behaviour's majorly annoying; time for the package manager to start
> enforcing things strictly.
My impression is that most ebuild developers tend to dis
On Sun, 08 Mar 2009 08:49:16 +0100
Tiziano Müller wrote:
> http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ
Here're some more easy ones.
First up, un-optionaling some optional things. No impact for developers:
* PROPERTIES must be cached properly (it's optional in current EAPIs)
Am Montag, den 09.03.2009, 10:12 +0100 schrieb Michael Haubenwallner:
> On Sun, 2009-03-08 at 21:22 -0700, Donnie Berkholz wrote:
>
> > I think the idea of ebuilds as scripts showing directly how to build
> > software is a core part of the Gentoo build-system philosophy. This
> > proposal pushes
Am Sonntag, den 08.03.2009, 23:31 -0700 schrieb Donnie Berkholz:
> On 21:22 Sun 08 Mar , Donnie Berkholz wrote:
> > On 23:35 Sun 08 Mar , Tiziano Müller wrote:
> > > Well, the point I'm trying to make here is a different one: The syntax
> > > you proposed is more to write but still equival
On Sun, 2009-03-08 at 21:22 -0700, Donnie Berkholz wrote:
> I think the idea of ebuilds as scripts showing directly how to build
> software is a core part of the Gentoo build-system philosophy. This
> proposal pushes ebuilds toward a formatted file that is not a script.
> Instead, it is more li
On 21:22 Sun 08 Mar , Donnie Berkholz wrote:
> On 23:35 Sun 08 Mar , Tiziano Müller wrote:
> > Well, the point I'm trying to make here is a different one: The syntax
> > you proposed is more to write but still equivalent to the one using
> > vars. And looking at the ebuilds - taking G2CON
On 23:35 Sun 08 Mar , Tiziano Müller wrote:
> Well, the point I'm trying to make here is a different one: The syntax
> you proposed is more to write but still equivalent to the one using
> vars. And looking at the ebuilds - taking G2CONF as an example - it
> seems that people don't have a pr
On Sun, Mar 08, 2009 at 09:42:29AM -0700, Donnie Berkholz wrote:
> On 08:49 Sun 08 Mar , Tiziano M?ller wrote:
> > So I think it's time for a short eapi bump with some distinct
> > improvements:
> >
> > http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ
>
> - I understand the reas
Am Sonntag, den 08.03.2009, 15:16 -0700 schrieb Donnie Berkholz:
> On 19:27 Sun 08 Mar , Tiziano Müller wrote:
> > Am Sonntag, den 08.03.2009, 10:01 -0700 schrieb Donnie Berkholz:
> > > It would just eliminate all but one call to use_with(). Depending on how
> > > many you've got, this can sho
On 19:27 Sun 08 Mar , Tiziano Müller wrote:
> Am Sonntag, den 08.03.2009, 10:01 -0700 schrieb Donnie Berkholz:
> > It would just eliminate all but one call to use_with(). Depending on how
> > many you've got, this can shorten things up a fair bit. Here's an
> > example:
> >
> > econf \
>
On 19:35 Sun 08 Mar , Tiziano Müller wrote:
> Am Sonntag, den 08.03.2009, 11:24 -0700 schrieb Donnie Berkholz:
> > On 10:01 Sun 08 Mar , Donnie Berkholz wrote:
> > > On 16:48 Sun 08 Mar , Ciaran McCreesh wrote:
> > > > On Sun, 8 Mar 2009 09:42:29 -0700
> > > > Donnie Berkholz wrote:
>
Am Sonntag, den 08.03.2009, 11:24 -0700 schrieb Donnie Berkholz:
> On 10:01 Sun 08 Mar , Donnie Berkholz wrote:
> > On 16:48 Sun 08 Mar , Ciaran McCreesh wrote:
> > > On Sun, 8 Mar 2009 09:42:29 -0700
> > > Donnie Berkholz wrote:
> > > > - I understand the reasoning for the SRC_CONFIGURE_W
Am Sonntag, den 08.03.2009, 17:22 +0100 schrieb Robert Buchholz:
> On Sunday 08 March 2009, Tiziano Müller wrote:
> > Hi everyone
> >
> > With eapis 1 and 2 we introduced nice features but also a couple of
> > new problems. One of them are the use dependencies when the package
> > you depend on doe
Am Sonntag, den 08.03.2009, 19:06 +0100 schrieb Stelian Ionescu:
> On Sun, 2009-03-08 at 08:49 +0100, Tiziano Müller wrote:
> > Hi everyone
> >
> > With eapis 1 and 2 we introduced nice features but also a couple of new
> > problems. One of them are the use dependencies when the package you
> > de
Am Sonntag, den 08.03.2009, 10:01 -0700 schrieb Donnie Berkholz:
> On 16:48 Sun 08 Mar , Ciaran McCreesh wrote:
> > On Sun, 8 Mar 2009 09:42:29 -0700
> > Donnie Berkholz wrote:
> > > - I understand the reasoning for the SRC_CONFIGURE_WITH blah stuff. I
> > > strongly oppose this implementatio
On 10:01 Sun 08 Mar , Donnie Berkholz wrote:
> On 16:48 Sun 08 Mar , Ciaran McCreesh wrote:
> > On Sun, 8 Mar 2009 09:42:29 -0700
> > Donnie Berkholz wrote:
> > > - I understand the reasoning for the SRC_CONFIGURE_WITH blah stuff. I
> > > strongly oppose this implementation because it mak
On Sun, 2009-03-08 at 08:49 +0100, Tiziano Müller wrote:
> Hi everyone
>
> With eapis 1 and 2 we introduced nice features but also a couple of new
> problems. One of them are the use dependencies when the package you
> depend on doesn't have the use flag anymore (see [1] for an example).
you can
On Sun, 08 Mar 2009 12:50:19 -0430
Jesus Rivero wrote:
> ~if python-2.6 is the selected interpreter and it misses the tk
> use flag. Is there a way to workaround this? am I missing something?
> or is just something else
> ~to take into account for next eapi?
Fixing this mess properly real
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, Mar 08, 2009 at 10:01:05AM -0700, Donnie Berkholz wrote:
> > How would that work? I can't see an obvious way of doing it that isn't
> > more or less as verbose as just using multiple calls.
>
> It would just eliminate all but one call to use_w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tiziano Müller wrote:
| Hi everyone
|
| With eapis 1 and 2 we introduced nice features but also a couple of new
| problems. One of them are the use dependencies when the package you
| depend on doesn't have the use flag anymore (see [1] for an exampl
On 16:48 Sun 08 Mar , Ciaran McCreesh wrote:
> On Sun, 8 Mar 2009 09:42:29 -0700
> Donnie Berkholz wrote:
> > - I understand the reasoning for the SRC_CONFIGURE_WITH blah stuff. I
> > strongly oppose this implementation because it makes ebuilds less
> > like bash scripts that are easy to unde
On Sun, 8 Mar 2009 09:42:29 -0700
Donnie Berkholz wrote:
> - I understand the reasoning for the SRC_CONFIGURE_WITH blah stuff. I
> strongly oppose this implementation because it makes ebuilds less
> like bash scripts that are easy to understand. Instead I suggest
> extending use_with() and use_en
On 08:49 Sun 08 Mar , Tiziano Müller wrote:
> So I think it's time for a short eapi bump with some distinct
> improvements:
>
> http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ
It's still being edited, so I have no idea whether I'm commenting on the
same version as was original
On Sunday 08 March 2009, Tiziano Müller wrote:
> Hi everyone
>
> With eapis 1 and 2 we introduced nice features but also a couple of
> new problems. One of them are the use dependencies when the package
> you depend on doesn't have the use flag anymore (see [1] for an
> example).
>
> So I think it'
Am Sonntag, den 08.03.2009, 12:05 +0100 schrieb Arfrever Frehtes
Taifersar Arahesis:
> 2009-03-08 10:43:44 Tiziano Müller napisał(a):
> > Am Sonntag, den 08.03.2009, 00:08 -0800 schrieb Josh Saddler:
> > > Tiziano Müller wrote:
> > > > Hi everyone
> > > >
> > > > With eapis 1 and 2 we introduced n
2009-03-08 10:43:44 Tiziano Müller napisał(a):
> Am Sonntag, den 08.03.2009, 00:08 -0800 schrieb Josh Saddler:
> > Tiziano Müller wrote:
> > > Hi everyone
> > >
> > > With eapis 1 and 2 we introduced nice features but also a couple of new
> > > problems. One of them are the use dependencies when t
> On Sun, 08 Mar 2009, Tiziano Müller wrote:
>> > http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ
I get "Not Found - Error 404" for this URL.
Ulrich
Am Sonntag, den 08.03.2009, 00:08 -0800 schrieb Josh Saddler:
> Tiziano Müller wrote:
> > Hi everyone
> >
> > With eapis 1 and 2 we introduced nice features but also a couple of new
> > problems. One of them are the use dependencies when the package you
> > depend on doesn't have the use flag anym
> On Sun, 8 Mar 2009, Ciaran McCreesh wrote:
> Last time I checked, every single use of foo? as a direct child of ||
> in the tree was wrong, as were the Portage docs. Let's say you have the
> following:
> DEPEND="|| (
> foo? ( cat/foo )
> bar? ( cat/bar )
> cat/ba
On Sun, 08 Mar 2009 00:08:37 -0800
Josh Saddler wrote:
> Is there a reason why we should ram through a new EAPI for something
> that *looks* like another "Paludis supports this so let's make it a
> Portage standard" proposal? Is there some kind of time deadline here
> that you all want?
If we wer
Tiziano Müller wrote:
> Hi everyone
>
> With eapis 1 and 2 we introduced nice features but also a couple of new
> problems. One of them are the use dependencies when the package you
> depend on doesn't have the use flag anymore (see [1] for an example).
>
> So I think it's time for a short eapi b
Hi everyone
With eapis 1 and 2 we introduced nice features but also a couple of new
problems. One of them are the use dependencies when the package you
depend on doesn't have the use flag anymore (see [1] for an example).
So I think it's time for a short eapi bump with some distinct
improvements:
59 matches
Mail list logo
