[gentoo-dev] Ideas for a (fast) EAPI=3

[gentoo-dev] Ideas for a (fast) EAPI=3

[Tiziano Müller]

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

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:

http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ


Please discuss.

Cheers,
Tiziano


[1]:
Git depends on subversion[dso], but subversion-1.5.5 doesn't have
USE=dso anymore, so my package manager (paludis in that case) tried to
downgrade to a version of subversion where the USE flag exists.
The PMS says this about the issue: "It is an error for a use dependency
to be applied to an ebuild which does not have the flag in question in
IUSE [...]"


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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Josh Saddler]

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

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 bump with some distinct
> improvements:
> 
> http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ

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?

Also, why the bannination of || ( foo? (.).) -- how is it error prone,
exactly.



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

[gentoo-dev] Re: Ideas for a (fast) EAPI=3

[Christian Faulhammer]

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

Hi,

Josh Saddler <nightmorph@gentoo.org>:

> 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 bump with some distinct
> > improvements:
> > 
> > http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ
> 
> 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?

 built_with_use supports exactly that with the --missing switch and
yesterday I noticed some ebuilds that could not be transferred to
EAPI 2 because of that.

> Also, why the bannination of || ( foo? (.).) -- how is it error prone,
> exactly.

 I would like to hear about that, too.

V-Li

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

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

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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Ciaran McCreesh]

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

On Sun, 08 Mar 2009 00:08:37 -0800
Josh Saddler <nightmorph@gentoo.org> 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 were sticking through "things Paludis has that're useful", the
list would be an awful lot longer... And not everything on that list is
even in Paludis... But hey, some things never go out of fashion.

A few things on the list are required pretty soon. Bug 249166 and
various existing screwups in the tree suggest that [use(+)] (or
whatever syntax is decided upon) is going to crop up fairly frequently.
And certain people are reluctant to nuke their prepalldocs calls
despite Council decisions... I think the rest are just there because
they're useful and easy.

> Also, why the bannination of || ( foo? (.).) -- how is it error prone,
> exactly.

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/baz
    )"

Then this is wrong:

    if use foo ; then
        myconf="--enable-foo"
    elif use bar ; then
        myconf="--enable-bar"
    else
        myconf="--enable-baz
    fi

Here's why:

Say the user already has baz installed, and has USE="foo". The package
manager will see that baz is already installed, and as per the rules
for || will not look at the foo or bar deps. So if the user doesn't
have foo installed, the --enable-foo will be wrong.

So the 'correct' code would have to be something like this:

    if use foo && has_version cat/foo ; then
        myconf="--enable-foo"
    elif use bar && has_version cat/bar ; then
        myconf="--enable-bar"
    else
        myconf="--enable-baz
    fi

Except this is *still* a mess, because a user who has USE="foo bar" is
going to end up with a differently configured package depending upon
what he happens to have installed up-front, which is something that's
not supposed to happen.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Ulrich Mueller]

>>>>> 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/baz
>     )"

> Then this is wrong:

>     if use foo ; then
>         myconf="--enable-foo"
>     elif use bar ; then
>         myconf="--enable-bar"
>     else
>         myconf="--enable-baz
>     fi

I would suspect that in most of such cases the code expresses what is
intended, but the dependency should be changed:

    foo? ( cat/foo )
    !foo? (
        bar? ( cat/bar )
        !bar? ( cat/baz )
    )

Ulrich

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Tiziano Müller]

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

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 anymore (see [1] for an example).
> > 
> > So I think it's time for a short eapi bump with some distinct
> > improvements:
> > 
> > http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ
> 
> 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?
Ok, first it's not about paludis,portage,pkgcore,whatever but about the
ebuild-format. Paludis also fails if you have DEPEND="cat/foo[moo]" in
bar-0.1.ebuild but cat/foo doesn't have a "moo" USE flag.

So, please let's focus on the problems we have and try to find a
solution. Please fill in the blanks in the table if you know how portage
has it implemented.

And I used the word "fast" because people start to use use-dependencies
on a larger scale leading to more problems like the one I described in
the example. In fact, you could already say that for git the dep-tree is
broken because newer subversion doesn't carry the "dso" USE flag
anymore.

>  Is there some kind of time deadline here
> that you all want?
Well, 2 weeks discussion and 1 month implementation would be cool.


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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Ulrich Mueller]

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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Arfrever Frehtes Taifersar Arahesis]

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

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 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:
> > > 
> > > http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ
> > 
> > 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?
> Ok, first it's not about paludis,portage,pkgcore,whatever but about the
> ebuild-format. Paludis also fails if you have DEPEND="cat/foo[moo]" in
> bar-0.1.ebuild but cat/foo doesn't have a "moo" USE flag.
> 
> So, please let's focus on the problems we have and try to find a
> solution. Please fill in the blanks in the table if you know how portage
> has it implemented.
> 
> And I used the word "fast" because people start to use use-dependencies
> on a larger scale leading to more problems like the one I described in
> the example. In fact, you could already say that for git the dep-tree is
> broken because newer subversion doesn't carry the "dso" USE flag
> anymore.

http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-util/subversion/subversion-1.5.5.ebuild?view=markup
contains:
IUSE="apache2 berkdb debug doc +dso emacs extras java nls perl python ruby sasl vim-syntax +webdav-neon webdav-serf"
                                ^^^

(Subversion 1.6.* also has "dso" USE flag.)

-- 
Arfrever Frehtes Taifersar Arahesis

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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Tiziano Müller]

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

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 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:
> > > > 
> > > > http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ
> > > 
> > > 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?
> > Ok, first it's not about paludis,portage,pkgcore,whatever but about the
> > ebuild-format. Paludis also fails if you have DEPEND="cat/foo[moo]" in
> > bar-0.1.ebuild but cat/foo doesn't have a "moo" USE flag.
> > 
> > So, please let's focus on the problems we have and try to find a
> > solution. Please fill in the blanks in the table if you know how portage
> > has it implemented.
> > 
> > And I used the word "fast" because people start to use use-dependencies
> > on a larger scale leading to more problems like the one I described in
> > the example. In fact, you could already say that for git the dep-tree is
> > broken because newer subversion doesn't carry the "dso" USE flag
> > anymore.
> 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-util/subversion/subversion-1.5.5.ebuild?view=markup
> contains:
> IUSE="apache2 berkdb debug doc +dso emacs extras java nls perl python ruby sasl vim-syntax +webdav-neon webdav-serf"
>                                 ^^^
True, but subversion-1.4* doesn't. Anyway, it was meant as an example...


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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Robert Buchholz]

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

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's time for a short eapi bump with some distinct
> improvements:
>
> http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ

I'm not sure if you would like to discuss items to be added to the 
spreadsheet on this list first, but I accidently added 
default_src_install (bug 33544) to the list. I did not know it would 
store and share changes immediately.
However, the proposed implementation on the bug does not follow the 
ideas of adding arguments to the default_src_* implementations 
(230725).

Still, I think adding the default src_install function to EAPI=3 would 
be both trivial and an improvement for many simple ebuilds.

Robert

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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Tiziano Müller]

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

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 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:
> >
> > http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ
> 
> I'm not sure if you would like to discuss items to be added to the 
> spreadsheet on this list first, but I accidently added 
> default_src_install (bug 33544) to the list. I did not know it would 
> store and share changes immediately.
This accident was intended ;-)

> However, the proposed implementation on the bug does not follow the 
> ideas of adding arguments to the default_src_* implementations 
> (230725).
> 
> Still, I think adding the default src_install function to EAPI=3 would 
> be both trivial and an improvement for many simple ebuilds.
Fine by me. I didn't add this bug because I thought that the discussion
about it could get too controversal and thus not suited for a fast
release of a new eapi (mainly thought to be fixing bugs).


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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Donnie Berkholz]

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

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 originally posted. Regardless, here's a few points 
on the version I'm reading:

- pkg_pretend() and a default src_install() would be excellent to have.

- docompress is good

- doheader/doinclude would be nice, same for dodoc -r, doins symlinks

- fixing problems in some existing features would be useful

- 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_enable() to accept multiple sets of arguments 
(alternately, making custom, similar functions that will take multiple 
args). Combined with the addition of src_configure() in EAPI=2, the 
amount of code could be a large reduction from existing versions without 
raising the barrier to entry.

-- 
Thanks,
Donnie

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

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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Ciaran McCreesh]

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

On Sun, 8 Mar 2009 09:42:29 -0700
Donnie Berkholz <dberkholz@gentoo.org> 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_enable() to accept multiple sets of
> arguments (alternately, making custom, similar functions that will
> take multiple args).

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.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Donnie Berkholz]

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

On 16:48 Sun 08 Mar     , Ciaran McCreesh wrote:
> On Sun, 8 Mar 2009 09:42:29 -0700
> Donnie Berkholz <dberkholz@gentoo.org> 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_enable() to accept multiple sets of
> > arguments (alternately, making custom, similar functions that will
> > take multiple args).
> 
> 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_with(). Depending on how 
many you've got, this can shorten things up a fair bit. Here's an 
example:

	econf \
		$(use_with 'x X' 'foo libfoo' 'bar' 'python pygtk')
	econf \
		$(use_with x X) \
		$(use_with foo libfoo) \
		$(use_with bar) \
		$(use_with python pygtk)


-- 
Thanks,
Donnie

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

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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[William Hubbs]

-----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_with(). Depending on how 
> many you've got, this can shorten things up a fair bit. Here's an 
> example:
> 
> 	econf \
> 		$(use_with 'x X' 'foo libfoo' 'bar' 'python pygtk')
> 	econf \
> 		$(use_with x X) \
> 		$(use_with foo libfoo) \
> 		$(use_with bar) \
> 		$(use_with python pygtk)
> 

I like this idea also, but I would prefer using something other than
spaces in each argument, like so:

econf \
	$(use_with x:X foo:libfoo bar python:pygtk)

- -- 
William Hubbs
gentoo accessibility team lead
williamh@gentoo.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkmz/zUACgkQblQW9DDEZTgnugCgkTMUOCQUbcAs9qcvxxmt2Wna
BY4AoKAjdpzXkiiizFsQ8MKUmAwHxZMC
=lFam
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Donnie Berkholz]

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

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 <dberkholz@gentoo.org> 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_enable() to accept multiple sets of
> > > arguments (alternately, making custom, similar functions that will
> > > take multiple args).
> > 
> > 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_with(). Depending on how 
> many you've got, this can shorten things up a fair bit. Here's an 
> example:
> 
> 	econf \
> 		$(use_with 'x X' 'foo libfoo' 'bar' 'python pygtk')
> 	econf \
> 		$(use_with x X) \
> 		$(use_with foo libfoo) \
> 		$(use_with bar) \
> 		$(use_with python pygtk)

And the straightforward evolution of this would be additional with() and 
enable() functions for mandatory support. I still find this more 
intuitive than the set of variables.

econf \
	$(use_with 'x X' 'foo libfoo' 'bar' 'python pygtk') \
	$(with foo bar blah baz) \
	$(enable bam paw tick)


-- 
Thanks,
Donnie

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

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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Tiziano Müller]

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

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 <dberkholz@gentoo.org> 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_enable() to accept multiple sets of
> > > > arguments (alternately, making custom, similar functions that will
> > > > take multiple args).
> > > 
> > > 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_with(). Depending on how 
> > many you've got, this can shorten things up a fair bit. Here's an 
> > example:
> > 
> > 	econf \
> > 		$(use_with 'x X' 'foo libfoo' 'bar' 'python pygtk')
> > 	econf \
> > 		$(use_with x X) \
> > 		$(use_with foo libfoo) \
> > 		$(use_with bar) \
> > 		$(use_with python pygtk)
> 
> And the straightforward evolution of this would be additional with() and 
> enable() functions for mandatory support. I still find this more 
> intuitive than the set of variables.
> 
> econf \
> 	$(use_with 'x X' 'foo libfoo' 'bar' 'python pygtk') \
> 	$(with foo bar blah baz) \
> 	$(enable bam paw tick)
> 

Which could already be written as ...
   econf --with-{foo,bar}
using bash :-)

(or did I miss the point?)


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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Donnie Berkholz]

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

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 <dberkholz@gentoo.org> 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_enable() to accept multiple sets of
> > > > > arguments (alternately, making custom, similar functions that will
> > > > > take multiple args).
> > > > 
> > > > 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_with(). Depending on how 
> > > many you've got, this can shorten things up a fair bit. Here's an 
> > > example:
> > > 
> > > 	econf \
> > > 		$(use_with 'x X' 'foo libfoo' 'bar' 'python pygtk')
> > > 	econf \
> > > 		$(use_with x X) \
> > > 		$(use_with foo libfoo) \
> > > 		$(use_with bar) \
> > > 		$(use_with python pygtk)
> > 
> > And the straightforward evolution of this would be additional with() and 
> > enable() functions for mandatory support. I still find this more 
> > intuitive than the set of variables.
> > 
> > econf \
> > 	$(use_with 'x X' 'foo libfoo' 'bar' 'python pygtk') \
> > 	$(with foo bar blah baz) \
> > 	$(enable bam paw tick)
> > 
> 
> Which could already be written as ...
>    econf --with-{foo,bar}
> using bash :-)
> 
> (or did I miss the point?)

Consistency, and that gets pretty ugly after a few when you also want to 
pass arguments to them.

-- 
Thanks,
Donnie

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

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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Tiziano Müller]

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

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 <dberkholz@gentoo.org> 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_enable() to accept multiple sets of
> > > arguments (alternately, making custom, similar functions that will
> > > take multiple args).
> > 
> > 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_with(). Depending on how 
> many you've got, this can shorten things up a fair bit. Here's an 
> example:
> 
> 	econf \
> 		$(use_with 'x X' 'foo libfoo' 'bar' 'python pygtk')
> 	econf \
> 		$(use_with x X) \
> 		$(use_with foo libfoo) \
> 		$(use_with bar) \
> 		$(use_with python pygtk)
> 
> 

The above could be rewritten to:

ECONF_USE_WITH="'x X' 'foo libfoo' 'bar' 'python pygtk'"
econf $(use_with ${ECONF_USE_WITH})

or an eclass could even export this:

src_configure() {
	[ -n ${ECONF_USE_WITH} ] && USE_WITH="$(use_with
\"${ECONF_USE_WITH}\")"
	econf ${USE_WITH}
}

Guessing from what I see in the gnome/kde eclasses I think people will
implement the above then in eclasses and I therefore don't see why we
can't do it like that from the beginning...
(Besides, there are already shortcuts in eclasses like G2CONF="...")


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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Donnie Berkholz]

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

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 \
> > 		$(use_with 'x X' 'foo libfoo' 'bar' 'python pygtk')
> 
> The above could be rewritten to:
> 
> ECONF_USE_WITH="'x X' 'foo libfoo' 'bar' 'python pygtk'"
> econf $(use_with ${ECONF_USE_WITH})

Why would I want to obfuscate my code like that by purposely making 
people look in multiple places to figure out what it's doing? I don't 
see how this is any improvement.

> or an eclass could even export this:
> 
> src_configure() {
> 	[ -n ${ECONF_USE_WITH} ] && USE_WITH="$(use_with
> \"${ECONF_USE_WITH}\")"
> 	econf ${USE_WITH}
> }
> 
> Guessing from what I see in the gnome/kde eclasses I think people will
> implement the above then in eclasses and I therefore don't see why we
> can't do it like that from the beginning...

If it can be implemented in an eclass, why would we want to do it as an 
EAPI in a package manager? Eclasses can be easily changed, you only need 
to write them once, and you don't have to deal with updating & approving 
a spec and new implementation for a bug in the previous implementation 
(which you have to retain indefinitely).

-- 
Thanks,
Donnie

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

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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Tiziano Müller]

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

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 shorten things up a fair bit. Here's an 
> > > example:
> > > 
> > > 	econf \
> > > 		$(use_with 'x X' 'foo libfoo' 'bar' 'python pygtk')
> > 
> > The above could be rewritten to:
> > 
> > ECONF_USE_WITH="'x X' 'foo libfoo' 'bar' 'python pygtk'"
> > econf $(use_with ${ECONF_USE_WITH})
> 
> Why would I want to obfuscate my code like that by purposely making 
> people look in multiple places to figure out what it's doing? I don't 
> see how this is any improvement.
> 
> > or an eclass could even export this:
> > 
> > src_configure() {
> > 	[ -n ${ECONF_USE_WITH} ] && USE_WITH="$(use_with
> > \"${ECONF_USE_WITH}\")"
> > 	econf ${USE_WITH}
> > }
> > 
> > Guessing from what I see in the gnome/kde eclasses I think people will
> > implement the above then in eclasses and I therefore don't see why we
> > can't do it like that from the beginning...
> 
> If it can be implemented in an eclass, why would we want to do it as an 
> EAPI in a package manager? Eclasses can be easily changed, you only need 
> to write them once, and you don't have to deal with updating & approving 
> a spec and new implementation for a bug in the previous implementation 
> (which you have to retain indefinitely).

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 problem with putting their config options into vars.
And furthermore with your syntax you still have to write out "econf
$(use_with ...)" explicitly while adding it the conf-vars to a var (as
proposed) makes the complete src_configure function obsolete, allows the
usage of the default src_configure/src_compile/src_install (see
http://archives.gentoo.org/gentoo-dev/msg_17e6ae8082aeb762fd01ba7307457789.xml for example) and is therefore even shorter to write.



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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Donnie Berkholz]

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

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 problem with putting their config 
> options into vars. And furthermore with your syntax you still have to 
> write out "econf $(use_with ...)" explicitly while adding it the 
> conf-vars to a var (as proposed) makes the complete src_configure 
> function obsolete, allows the usage of the default 
> src_configure/src_compile/src_install (see 
> http://archives.gentoo.org/gentoo-dev/msg_17e6ae8082aeb762fd01ba7307457789.xml 
> for example) and is therefore even shorter to write.

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 like an Ant XML file that more abstractly describes 
a build. I think this is the wrong direction for ebuilds because they 
should directly resemble how software is built by hand.

One of the key reasons people use Gentoo is that ebuilds are so easy to 
"get" for anyone who has ever built software by hand. I will continue to 
vehemently defend anything that I think retains this key advantage of 
Gentoo over other distributions.

-- 
Thanks,
Donnie

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

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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Donnie Berkholz]

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

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 G2CONF as an example - it 
> > seems that people don't have a problem with putting their config 
> > options into vars. And furthermore with your syntax you still have to 
> > write out "econf $(use_with ...)" explicitly while adding it the 
> > conf-vars to a var (as proposed) makes the complete src_configure 
> > function obsolete, allows the usage of the default 
> > src_configure/src_compile/src_install (see 
> > http://archives.gentoo.org/gentoo-dev/msg_17e6ae8082aeb762fd01ba7307457789.xml 
> > for example) and is therefore even shorter to write.
> 
> 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 like an Ant XML file that more abstractly describes 
> a build. I think this is the wrong direction for ebuilds because they 
> should directly resemble how software is built by hand.
> 
> One of the key reasons people use Gentoo is that ebuilds are so easy to 
> "get" for anyone who has ever built software by hand. I will continue to 
> vehemently defend anything that I think retains this key advantage of 
> Gentoo over other distributions.

To return to the original point of this whole thread, your goal was to 
get EAPI=3 through fairly quickly without tons of controversial points. 
I don't think this component qualifies. Feel free to bring it up again 
for 4.

-- 
Thanks,
Donnie

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

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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Tiziano Müller]

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

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 equivalent to the one using 
> > > vars. And looking at the ebuilds - taking G2CONF as an example - it 
> > > seems that people don't have a problem with putting their config 
> > > options into vars. And furthermore with your syntax you still have to 
> > > write out "econf $(use_with ...)" explicitly while adding it the 
> > > conf-vars to a var (as proposed) makes the complete src_configure 
> > > function obsolete, allows the usage of the default 
> > > src_configure/src_compile/src_install (see 
> > > http://archives.gentoo.org/gentoo-dev/msg_17e6ae8082aeb762fd01ba7307457789.xml 
> > > for example) and is therefore even shorter to write.
> > 
> > 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 like an Ant XML file that more abstractly describes 
> > a build. I think this is the wrong direction for ebuilds because they 
> > should directly resemble how software is built by hand.
> > 
> > One of the key reasons people use Gentoo is that ebuilds are so easy to 
> > "get" for anyone who has ever built software by hand. I will continue to 
> > vehemently defend anything that I think retains this key advantage of 
> > Gentoo over other distributions.
> 
> To return to the original point of this whole thread, your goal was to 
> get EAPI=3 through fairly quickly without tons of controversial points. 
> I don't think this component qualifies. Feel free to bring it up again 
> for 4.

Wanted to say the same thing. Removed from the list.


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

[gentoo-dev] Re: Ideas for a (fast) EAPI=3

[Christian Faulhammer]

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

Hallo,

Donnie Berkholz <dberkholz@gentoo.org>:
> 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 problem with putting
> > their config options into vars. And furthermore with your syntax
> > you still have to write out "econf $(use_with ...)" explicitly
> > while adding it the conf-vars to a var (as proposed) makes the
> > complete src_configure function obsolete, allows the usage of the
> > default src_configure/src_compile/src_install (see 
> > http://archives.gentoo.org/gentoo-dev/msg_17e6ae8082aeb762fd01ba7307457789.xml 
> > for example) and is therefore even shorter to write.
> 
> 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 like an Ant XML file that more abstractly
> describes a build. I think this is the wrong direction for ebuilds
> because they should directly resemble how software is built by hand.

 I agree with you here, the saving of space by not defining a custom
src_configure() stands against readability for non-developers (also
known as people who do not work with ebuilds on a daily basis but still
regularly).  We gain only a little bit.

V-Li

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

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

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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[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 ebuilds toward a formatted file that is not a script. 
> Instead, it is more like an Ant XML file that more abstractly describes 
> a build. I think this is the wrong direction for ebuilds because they 
> should directly resemble how software is built by hand.

Fully agreed here, "keep it simple software".
Even if there are slightly more bits to write in the ebuilds.

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Tobias Scherbaum]

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

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 ebuilds toward a formatted file that is not a script. 
> > Instead, it is more like an Ant XML file that more abstractly describes 
> > a build. I think this is the wrong direction for ebuilds because they 
> > should directly resemble how software is built by hand.
> 
> Fully agreed here, "keep it simple software".
> Even if there are slightly more bits to write in the ebuilds.

dito, fully agreed.

  Tobias

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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Thomas Anderson]

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

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 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_enable() to accept multiple sets of arguments 
> (alternately, making custom, similar functions that will take multiple 
> args). Combined with the addition of src_configure() in EAPI=2, the 
> amount of code could be a large reduction from existing versions without 
> raising the barrier to entry.

While I understand your concerns about the SRC_CONFIGURE stuff, there
are two points I'd like to make;
1) The barrier to entry is negligible. How much more difficult is it for
someone to learn what CONFIGURE_ENABLES=( 'foo foobar' ) ? I didn't find
it difficult at all(and I've used them).
2) src_configure is just one part; src_compile has uses as does
src_install. In fact, if you want to do patches, src_prepare would be in
there too. What I'm saying is that focusing on the one part(configure)
is ignoring the good part of the rest of the proposal.

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

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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Jesus Rivero]

-----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 example).
Hello all,

~    Now that this topic was brought to light, I would like to add 
another point...

~    I'm not sure if this has been worked out, or I just don't know how 
it is done, but a lot of python packages
~    need to check use flags for dev-lang/python, like tk or threads for 
example. Now this is tricky considering the slotting of
~    the interpreter. Let me give you an example:

~    Suppose I have both python-2.5 and python-2.6 installed. python-2.5 
was installed with tk use flag enabled but python-2.6 has it disabled.
~    When some package tries to check for foo? ( dev-lang/python[tk] ) 
it will merge nicely because the use dep restriction is achieved with 
python-2.5, even
~    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?


~    Thanks a lot,

~    Best regards,

~    Jesus Rivero (Neurogeek)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmz/lMACgkQdIssYB9vBoPEbwCfYg/BaEhRtNCv1LChbqdAt8RW
T8oAmwaA6Jz2HX5NbSHhD3XeN7JnqAHL
=oJr/
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Ciaran McCreesh]

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

On Sun, 08 Mar 2009 12:50:19 -0430
Jesus Rivero <neurogeek@gentoo.org> 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 really requires package manager support for
multiple ABIs (for some value of B that includes things like Python
versions). I doubt this is fixable in the timeframe that seems to be
being considered here.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Stelian Ionescu]

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

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 solve this right now, even if in a not very elegant way. For
instance, if you need glibc with NPTL support, you can use 
elibc_glibc? ( >=sys-libs/glibc-2.3
               || ( <sys-libs/glibc-2.6[nptl]
		    >=sys-libs/glibc-2.6 ) )

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.


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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Tiziano Müller]

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

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
> > depend on doesn't have the use flag anymore (see [1] for an example).
> 
> you can solve this right now, even if in a not very elegant way. For
> instance, if you need glibc with NPTL support, you can use 
> elibc_glibc? ( >=sys-libs/glibc-2.3
>                || ( <sys-libs/glibc-2.6[nptl]
> 		    >=sys-libs/glibc-2.6 ) )
> 

Well, that's exactly what could be avoided and eventually be written as:
    "elibc_glibc? ( >=sys-libs/glibc-2.3[nptl(+)] )"


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

[gentoo-dev] Re: Ideas for a (fast) EAPI=3

[Christian Faulhammer]

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

Hi,

Tiziano Müller <dev-zero@gentoo.org>:
> 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).

 I don't know if there is a bug somewhere (I did not find one), but
what about having the possibility to ask for one out many USE flags of
a dependency.  For example app-misc/gramps needs dev-lang/python with
USE=berkdb or USE=sqlite, but Portage won't tell the user that he can
enable one but always asks for the first in the || () string.

V-Li

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

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

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

Re: [gentoo-dev] Re: Ideas for a (fast) EAPI=3

[Daniel Pielmeier]

2009/3/9 Christian Faulhammer <fauli@gentoo.org>:
>
>  I don't know if there is a bug somewhere (I did not find one), but
> what about having the possibility to ask for one out many USE flags of
> a dependency.  For example app-misc/gramps needs dev-lang/python with
> USE=berkdb or USE=sqlite, but Portage won't tell the user that he can
> enable one but always asks for the first in the || () string.
>

|| ( dev-lang/python[berkdb] dev-lang/python[sqlite] )

I had a similar case recently and detected another problem if you try
to switch from one possibility to the other.

Say you have python with berkdb compiled to satisfy the dependency and
then set "dev-lang/python -berkdb sqlite" in package.use. After this
world dependency calculation will fail.

The only way I found to get around this is to recompile python with
the new use flags first. Afterwards dependency calculation succeeds.

-- 
Regards,
Daniel

[gentoo-dev] Re: Ideas for a (fast) EAPI=3

[Christian Faulhammer]

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

Hi,

Daniel Pielmeier <daniel.pielmeier@googlemail.com>:

> 2009/3/9 Christian Faulhammer <fauli@gentoo.org>:
> >
> >  I don't know if there is a bug somewhere (I did not find one), but
> > what about having the possibility to ask for one out many USE flags
> > of a dependency.  For example app-misc/gramps needs dev-lang/python
> > with USE=berkdb or USE=sqlite, but Portage won't tell the user that
> > he can enable one but always asks for the first in the || () string.
> >
> 
> || ( dev-lang/python[berkdb] dev-lang/python[sqlite] )

 That's the solution currently and not the optimum.
 
> The only way I found to get around this is to recompile python with
> the new use flags first. Afterwards dependency calculation succeeds.

 Well spotted.

V-Li

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

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

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

Re: [gentoo-dev] Re: Ideas for a (fast) EAPI=3

[Daniel Pielmeier]

2009/3/9 Christian Faulhammer <fauli@gentoo.org>:
> Hi,
>
> Daniel Pielmeier <daniel.pielmeier@googlemail.com>:
>>
>> || ( dev-lang/python[berkdb] dev-lang/python[sqlite] )
>
>  That's the solution currently and not the optimum.
>

I have discussed this yesterday with loki_val, and workaround would be
using a useflag for one database backend and if it is deactivated use
the other.

!berkdb? dev-lang/python[sqlite]
berkdb? dev-lang/python[berkdb]

-- 
Regards,
Daniel

Re: [gentoo-dev] Re: Ideas for a (fast) EAPI=3

[Tiziano Müller]

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

Am Montag, den 09.03.2009, 10:06 +0100 schrieb Christian Faulhammer:
> Hi,
> 
> Daniel Pielmeier <daniel.pielmeier@googlemail.com>:
> 
> > 2009/3/9 Christian Faulhammer <fauli@gentoo.org>:
> > >
> > >  I don't know if there is a bug somewhere (I did not find one), but
> > > what about having the possibility to ask for one out many USE flags
> > > of a dependency.  For example app-misc/gramps needs dev-lang/python
> > > with USE=berkdb or USE=sqlite, but Portage won't tell the user that
> > > he can enable one but always asks for the first in the || () string.
> > >
> > 
> > || ( dev-lang/python[berkdb] dev-lang/python[sqlite] )
> 
>  That's the solution currently and not the optimum.
>  
> > The only way I found to get around this is to recompile python with
> > the new use flags first. Afterwards dependency calculation succeeds.
> 

Correctly you should probably add a berkdb or sqlite USE flag to gramps
and then do:
sqlite? ( dev-lang/python[sqlite] )
!sqlite? ( dev-lang/python[berkdb] )

Because if the user currently installs gramps and has
dev-lang/python[sqlite] and then later decides to reinstall
dev-lang/python with USE=-sqlite, everything's fine from a package
managers view as long as dev-lang/python has at least USE=berkdb, but
the user looses the data in gramps.

Well, even then it's not safe since it's python and gramps may offer
berkdb as a storage backend even if USE=sqlite, so you should patch
gramps to blend out what's not available from a dependency
perspective...



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

[gentoo-dev] Re: Ideas for a (fast) EAPI=3

[Christian Faulhammer]

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

Hi,

Tiziano Müller <dev-zero@gentoo.org>:

> Am Montag, den 09.03.2009, 10:06 +0100 schrieb Christian Faulhammer:
> > Hi,
> > 
> > Daniel Pielmeier <daniel.pielmeier@googlemail.com>:
> > 
> > > 2009/3/9 Christian Faulhammer <fauli@gentoo.org>:
> > > >
> > > >  I don't know if there is a bug somewhere (I did not find one),
> > > > but what about having the possibility to ask for one out many
> > > > USE flags of a dependency.  For example app-misc/gramps needs
> > > > dev-lang/python with USE=berkdb or USE=sqlite, but Portage
> > > > won't tell the user that he can enable one but always asks for
> > > > the first in the || () string.
> > > >
> > > 
> > > || ( dev-lang/python[berkdb] dev-lang/python[sqlite] )
> > 
> >  That's the solution currently and not the optimum.
> >  
> > > The only way I found to get around this is to recompile python
> > > with the new use flags first. Afterwards dependency calculation
> > > succeeds.
> > 
> 
> Correctly you should probably add a berkdb or sqlite USE flag to
> gramps and then do:
> sqlite? ( dev-lang/python[sqlite] )
> !sqlite? ( dev-lang/python[berkdb] )

 The latest version 3.1 only needs USE=berkdb on Python...so problem
solved for me. :)

V-Li

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

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

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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Ciaran McCreesh]

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

On Sun, 08 Mar 2009 08:49:16 +0100
Tiziano Müller <dev-zero@gentoo.org> 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)

* DEFINED_PHASES must be supported (ditto)

Next, some probably easy but long standing features:

* src_test run unless RESTRICTed or explicitly disabled by the user (bug
  184812)

* have econf run ./configure with --disable-dependency-tracking and
  --enable-fast-install (bug 211529)

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

Some things we should probably sort out:

* The list of extensions for unpack probably needs a couple of new
  things.

* Provide ebuilds a way to differentiate between updates and removals
  (bug 205557), since the way devmanual says to do it got broken by a
  non-EAPIed change. This one's slightly trickier than initially
  apparent, because a solution's needed for the weird cases. One
  example is if you have foo-1:1 and foo-2:2 installed, and you're
  installing foo-2:1. In this case, it's both a reinstall and an
  upgrade. One possibility is a REPLACING_VERSIONS variable that
  contains a list of all versions being replaced, along with a
  REPLACED_BY_VERSION variable for the pre/postrm part.

Not sure if these can go in in time for Portage or not:

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

* Calling unpack on an unrecognised extension should be fatal, unless
  --if-compressed is specified. The default src_unpack needs to use
  this.

* pkg_info should work on things that aren't installed, as well as
  things that are.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Zac Medico]

-----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 dislike the
idea of adding profile-specific flags such as $ARCH, userland_*,
kernel_*, and elibc_* to IUSE. Perhaps there should be exemptions
for these?
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (GNU/Linux)

iEUEARECAAYFAkm1gnIACgkQ/ejvha5XGaN8pACYh2FTD9clbUo/kR4xoWi5z1kj
KQCdHjyFkhiz7DdSDbCRGrOraayLrRE=
=HgYu
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Ciaran McCreesh]

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

On Mon, 09 Mar 2009 13:56:19 -0700
Zac Medico <zmedico@gentoo.org> 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 developers tend to dislike the
> idea of adding profile-specific flags such as $ARCH, userland_*,
> kernel_*, and elibc_* to IUSE. Perhaps there should be exemptions
> for these?

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_EXPAND_VALUES_KERNEL="linux blah"
    USE_EXPAND_VALUES_ELIBC="glibc"
    USE_EXPAND_VALUES_ARCH="x86 amd64 sparc mips blah"

so we've got an enforcable complete list of every legal value for
them, and less associated mess?

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Zac Medico]

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

Ciaran McCreesh wrote:
> On Mon, 09 Mar 2009 13:56:19 -0700
> Zac Medico <zmedico@gentoo.org> 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 developers tend to dislike the
>> idea of adding profile-specific flags such as $ARCH, userland_*,
>> kernel_*, and elibc_* to IUSE. Perhaps there should be exemptions
>> for these?
> 
> 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_EXPAND_VALUES_KERNEL="linux blah"
>     USE_EXPAND_VALUES_ELIBC="glibc"
>     USE_EXPAND_VALUES_ARCH="x86 amd64 sparc mips blah"
> 
> so we've got an enforcable complete list of every legal value for
> them, and less associated mess?

That seems like a reasonable approach. What about flags that are
commonly forced or masked such as selinux or multilib? Should there
be an implicit exemption for all forced/masked flags, or should we
introduce an IMPLICIT_IUSE profile variable to enumerate specific
ones which are implicit members of IUSE?
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (GNU/Linux)

iEYEARECAAYFAkm1ig8ACgkQ/ejvha5XGaMpxwCgqi0Ma+Wv9s0coMYtagWR8Je/
hBEAn3awatpk505DxKrGtYDwTSYgn+nZ
=XHzp
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Ciaran McCreesh]

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

On Mon, 09 Mar 2009 14:28:48 -0700
Zac Medico <zmedico@gentoo.org> 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_EXPAND_VALUES_KERNEL="linux blah"
> >     USE_EXPAND_VALUES_ELIBC="glibc"
> >     USE_EXPAND_VALUES_ARCH="x86 amd64 sparc mips blah"
> > 
> > so we've got an enforcable complete list of every legal value for
> > them, and less associated mess?
> 
> That seems like a reasonable approach. What about flags that are
> commonly forced or masked such as selinux or multilib? Should there
> be an implicit exemption for all forced/masked flags, or should we
> introduce an IMPLICIT_IUSE profile variable to enumerate specific
> ones which are implicit members of IUSE?

I'd rather we were explicit about what's implicit. All forced / masked
flags is a pretty large set.

-- 
Ciaran McCreesh

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

[gentoo-dev] Re: Ideas for a (fast) EAPI=3

[Christian Faulhammer]

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

Hi,

Ciaran McCreesh <ciaran.mccreesh@googlemail.com>:
> Next, some probably easy but long standing features:
> 
> * src_test run unless RESTRICTed or explicitly disabled by the user
> (bug 184812)

 A big no.  This will lead to many failures on user systems, people who
run stable will be greatly annoyed.  I know this is inspired by good
intentions, but will not have the desired effect.

 The rest looks ok.

V-Li

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

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

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

Re: [gentoo-dev] Re: Ideas for a (fast) EAPI=3

[Ciaran McCreesh]

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

On Mon, 9 Mar 2009 22:33:11 +0100
Christian Faulhammer <fauli@gentoo.org> wrote:
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com>:
> > Next, some probably easy but long standing features:
> > 
> > * src_test run unless RESTRICTed or explicitly disabled by the user
> > (bug 184812)
> 
>  A big no.  This will lead to many failures on user systems, people
> who run stable will be greatly annoyed.  I know this is inspired by
> good intentions, but will not have the desired effect.

People who run stable won't see test failures, because developers and
arch testers and ~arch users will all have run the tests already and
made sure there aren't any failures. And if there *are* failures that
make it past all three levels of checking before stable, they really
need to be investigated -- chances are they're showing a legitimate
problem.

-- 
Ciaran McCreesh

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

[gentoo-dev] Re: Ideas for a (fast) EAPI=3

[Christian Faulhammer]

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

Hi,

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

> On Mon, 9 Mar 2009 22:33:11 +0100
> Christian Faulhammer <fauli@gentoo.org> wrote:
> > Ciaran McCreesh <ciaran.mccreesh@googlemail.com>:
> > > Next, some probably easy but long standing features:
> > > 
> > > * src_test run unless RESTRICTed or explicitly disabled by the
> > > user (bug 184812)
> > 
> >  A big no.  This will lead to many failures on user systems, people
> > who run stable will be greatly annoyed.  I know this is inspired by
> > good intentions, but will not have the desired effect.
> 
> People who run stable won't see test failures, because developers and
> arch testers and ~arch users will all have run the tests already and
> made sure there aren't any failures. And if there *are* failures that
> make it past all three levels of checking before stable, they really
> need to be investigated -- chances are they're showing a legitimate
> problem.

 Package A goes stable, test suite passes.  Package B (a dependency of
A) goes stable in a newer version, which will cause A to not merge in
stable profile.  This happens all the time and is no special case.

V-Li

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

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

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

Re: [gentoo-dev] Re: Ideas for a (fast) EAPI=3

[Ciaran McCreesh]

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

On Mon, 9 Mar 2009 23:20:03 +0100
Christian Faulhammer <fauli@gentoo.org> wrote:
>  Package A goes stable, test suite passes.  Package B (a dependency of
> A) goes stable in a newer version, which will cause A to not merge in
> stable profile.  This happens all the time and is no special case.

Uh, you *are* testing things that use a library before you stable that
library, right?

Besides, if a newer version of a library breaks a package using it, you
most definitely want to know about it before you end up merging
something that won't work. If src_test is failing where it used to
work, it's a very good sign that something's broken, and you shouldn't
be carrying on.

-- 
Ciaran McCreesh

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

[gentoo-dev] Re: Ideas for a (fast) EAPI=3

[Christian Faulhammer]

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

Hi,

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

> On Mon, 9 Mar 2009 23:20:03 +0100
> Christian Faulhammer <fauli@gentoo.org> wrote:
> >  Package A goes stable, test suite passes.  Package B (a dependency
> > of A) goes stable in a newer version, which will cause A to not
> > merge in stable profile.  This happens all the time and is no
> > special case.
> 
> Uh, you *are* testing things that use a library before you stable that
> library, right?

 When I was an architecture developer I tried to.  But when stabilising
a minor version of curl (for example), testing all reverse dependencies
is no option.  But this broke tests for Bazaar for example in stable.
 Or another issue.  Badly written Autoconf systems which will break in
src_test() with a different version of intltool, which is not a direct
dependency.  That pitfall hit me several times in the last years.
 The more, x86 e.g. ranges from embedded Geode platforms to dual core
desktop systems and running the sqlite test suite on the first is no
fun.  As a user I would not accept two hours of build time.
 Test-driven development is great, but not so widely used as one could
wish it to be.

> Besides, if a newer version of a library breaks a package using it,
> you most definitely want to know about it before you end up merging
> something that won't work. If src_test is failing where it used to
> work, it's a very good sign that something's broken, and you shouldn't
> be carrying on.

 Arch devs run test suites and won't stabilise if it fails (except some
special cases).

V-Li

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

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

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

Re: [gentoo-dev] Re: Ideas for a (fast) EAPI=3

[Ciaran McCreesh]

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

On Tue, 10 Mar 2009 00:25:49 +0100
Christian Faulhammer <fauli@gentoo.org> wrote:
> > Uh, you *are* testing things that use a library before you stable
> > that library, right?
> 
>  When I was an architecture developer I tried to.  But when
> stabilising a minor version of curl (for example), testing all
> reverse dependencies is no option.  But this broke tests for Bazaar
> for example in stable.

Then this is a legitimate problem that someone needs to know about and
fix. So having src_test turned on globally is a *good* thing.

> Badly written Autoconf systems which will break in src_test() with a
> different version of intltool, which is not a direct dependency.

Again, finding this is good.

> That pitfall hit me several times in the last years. The more, x86
> e.g. ranges from embedded Geode platforms to dual core desktop
> systems and running the sqlite test suite on the first is no fun.  As
> a user I would not accept two hours of build time. Test-driven
> development is great, but not so widely used as one could wish it to
> be.

And if you're on an especially slow platform, as a user you can turn
tests off.

-- 
Ciaran McCreesh

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

[gentoo-dev] Re: Ideas for a (fast) EAPI=3

[Christian Faulhammer]

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

Hi,

Ciaran McCreesh <ciaran.mccreesh@googlemail.com>:
> Then this is a legitimate problem that someone needs to know about and
> fix. So having src_test turned on globally is a *good* thing.
> 
[...]
> 
> Again, finding this is good.
[...]
> 
> And if you're on an especially slow platform, as a user you can turn
> tests off.

 Ciaran, your initial argument was that stable users won't see those
failures as architecture teams will spot them during stabilisation.
This is wrong, above cases will turn up after a successful
stabilisation with full QA.  Nobody ever said, that spotting those is
bad, so for me this discussion has ended.  Enabling by default for
everyone (not all users are experts, like it or not) is a bad idea as
it causes many false positives and has drawbacks for just-users.
 For me following your turns and twists through a discussion is not
worth my time.

V-Li

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

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

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

Re: [gentoo-dev] Re: Ideas for a (fast) EAPI=3

[Ciaran McCreesh]

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

On Tue, 10 Mar 2009 17:11:56 +0100
Christian Faulhammer <fauli@gentoo.org> wrote:
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com>:
> > Then this is a legitimate problem that someone needs to know about
> > and fix. So having src_test turned on globally is a *good* thing.
> > 
> [...]
> > 
> > Again, finding this is good.
> [...]
> > 
> > And if you're on an especially slow platform, as a user you can turn
> > tests off.
> 
>  Ciaran, your initial argument was that stable users won't see those
> failures as architecture teams will spot them during stabilisation.

Unless there is a genuine problem, yes.

> This is wrong, above cases will turn up after a successful
> stabilisation with full QA.

And they indicate a genuine problem, so you want them to show up.

> Nobody ever said, that spotting those is bad, so for me this
> discussion has ended.  Enabling by default for everyone (not all
> users are experts, like it or not) is a bad idea as it causes many
> false positives and has drawbacks for just-users.

So? The occasional false positive, which can quickly be fixed, is a lot
better than missing things that will break a user's system. We should
be failing safely, not defaulting to dangerous behaviour.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: Ideas for a (fast) EAPI=3

[Alec Warner]

On Mon, Mar 9, 2009 at 3:25 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Mon, 9 Mar 2009 23:20:03 +0100
> Christian Faulhammer <fauli@gentoo.org> wrote:
>>  Package A goes stable, test suite passes.  Package B (a dependency of
>> A) goes stable in a newer version, which will cause A to not merge in
>> stable profile.  This happens all the time and is no special case.
>
> Uh, you *are* testing things that use a library before you stable that
> library, right?

You can't test everything.  I think for a small project like exherbo
where everyone basically sees eye to eye on a number of ideas this
works great.  Everyone agrees testing is super and they will fix
broken tests or RESTRICT them.  But Gentoo is bigger, and people have
varying opinions, and on this topic the opinions are rather strong; so
I kindly ask that you drop it.  There are plenty of other far more
useful features on your list that are worth your time and will
actually slide through rather quickly ;)

>
> Besides, if a newer version of a library breaks a package using it, you
> most definitely want to know about it before you end up merging
> something that won't work. If src_test is failing where it used to
> work, it's a very good sign that something's broken, and you shouldn't
> be carrying on.
>
> --
> Ciaran McCreesh
>

Re: [gentoo-dev] Re: Ideas for a (fast) EAPI=3

[Ciaran McCreesh]

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

On Mon, 9 Mar 2009 20:58:40 -0700
Alec Warner <antarus@gentoo.org> wrote:
> You can't test everything.  I think for a small project like exherbo
> where everyone basically sees eye to eye on a number of ideas this
> works great.  Everyone agrees testing is super and they will fix
> broken tests or RESTRICT them.  But Gentoo is bigger, and people have
> varying opinions, and on this topic the opinions are rather strong; so
> I kindly ask that you drop it.  There are plenty of other far more
> useful features on your list that are worth your time and will
> actually slide through rather quickly ;)

Well, the alternative is to drop src_test all together. If a test
failure is meaningless, having the test is meaningless.

-- 
Ciaran McCreesh

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

[gentoo-dev] Re: Ideas for a (fast) EAPI=3

[Christian Faulhammer]

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

Hi,

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

> On Mon, 9 Mar 2009 20:58:40 -0700
> Alec Warner <antarus@gentoo.org> wrote:
> > You can't test everything.  I think for a small project like exherbo
> > where everyone basically sees eye to eye on a number of ideas this
> > works great.  Everyone agrees testing is super and they will fix
> > broken tests or RESTRICT them.  But Gentoo is bigger, and people
> > have varying opinions, and on this topic the opinions are rather
> > strong; so I kindly ask that you drop it.  There are plenty of
> > other far more useful features on your list that are worth your
> > time and will actually slide through rather quickly ;)
> 
> Well, the alternative is to drop src_test all together. If a test
> failure is meaningless, having the test is meaningless.

 No, some software like in sci-* has test suites that a user wants to
run probably before productively using that software.  But the user
should opt for and not against it.

V-Li

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

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

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

Re: [gentoo-dev] Re: Ideas for a (fast) EAPI=3

[Ciaran McCreesh]

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

On Tue, 10 Mar 2009 17:00:05 +0100
Christian Faulhammer <fauli@gentoo.org> wrote:
> > Well, the alternative is to drop src_test all together. If a test
> > failure is meaningless, having the test is meaningless.
> 
>  No, some software like in sci-* has test suites that a user wants to
> run probably before productively using that software.  But the user
> should opt for and not against it.

You're saying that users want to have something installed that they
aren't going to use productively?

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: Ideas for a (fast) EAPI=3

[Maciej Mrozowski]

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

On Monday 09 of March 2009 22:36:33 Ciaran McCreesh wrote:
> On Mon, 9 Mar 2009 22:33:11 +0100
>
> Christian Faulhammer <fauli@gentoo.org> wrote:
> > Ciaran McCreesh <ciaran.mccreesh@googlemail.com>:
> > > Next, some probably easy but long standing features:
> > >
> > > * src_test run unless RESTRICTed or explicitly disabled by the user
> > > (bug 184812)
> >
> >  A big no.  This will lead to many failures on user systems, people
> > who run stable will be greatly annoyed.  I know this is inspired by
> > good intentions, but will not have the desired effect.
>
> People who run stable won't see test failures, because developers and
> arch testers and ~arch users will all have run the tests already and
> made sure there aren't any failures. And if there *are* failures that
> make it past all three levels of checking before stable, they really
> need to be investigated -- chances are they're showing a legitimate
> problem.

Unfortunately upstream tends to think of tests in very relaxed way. Some 
critical packages, like openssl are thoroughly tested for regressions and are 
already supplied with complete unit test modules. There's unfortunately the 
problem with let's call them "desktop" packages, where having test suite 
compile at all (not talking about running it successfully) can be considered 
luck. What are packagers supposed to do in such case?
- hold the package in stasis in some overlay and push upstream to fix the issue 
they're probably not willing/understaffed to - when fixed - push to tree?
- fix test suit by themselves?
- RESTRICT=test in affected package?
It all depends on what one tries to achieve. I'm quite certain that user of 
average distribution (even source based) is not particularly interested in 
*actively* participating in software testing process with all consequences 
like not getting something built just because some minor unit test failed for 
him. That kind of package maintenance should be left *only* for packagers imho 
(if not taken care of upstream developers already).
Also the problem is with numbers - such global change (like enabling src_test 
stage for every package by default unless restricted) will immediately affect 
all packages in tree.
Thus I wouldn't recommend converting user environments into tinderbox.

-- 
regards
MM

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

Re: [gentoo-dev] Re: Ideas for a (fast) EAPI=3

[Ciaran McCreesh]

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

On Mon, 9 Mar 2009 23:24:15 +0100
Maciej Mrozowski <reavertm@poczta.fm> wrote:
> Unfortunately upstream tends to think of tests in very relaxed way.

And for those upstreams that do, you RESTRICT=test, or better yet
filter out dodgy tests. Which is what you should be doing currently
anyway -- the difference is, with EAPI 3 you'll have to go out of your
way to do the wrong thing, as opposed to now where you have to go out
of your way to do the right thing.

> Also the problem is with numbers - such global change (like enabling
> src_test stage for every package by default unless restricted) will
> immediately affect all packages in tree.

Uhm. See this thread being about EAPI 3?

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Donnie Berkholz]

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

On 20:26 Mon 09 Mar     , Ciaran McCreesh wrote:
> On Sun, 08 Mar 2009 08:49:16 +0100
> Tiziano Müller <dev-zero@gentoo.org> 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 176467). The existing
>   behaviour's majorly annoying; time for the package manager to start
>   enforcing things strictly.

I really like this one, and I've wanted it for a wihle.

> Not sure if these can go in in time for Portage or not:
> 
> * 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 splatting).

Sounds useful to have less '|| die' all over the place.

> * Calling unpack on an unrecognised extension should be fatal, unless
>   --if-compressed is specified. The default src_unpack needs to use
>   this.

Why?

-- 
Thanks,
Donnie

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

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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Ciaran McCreesh]

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

On Mon, 9 Mar 2009 15:39:41 -0700
Donnie Berkholz <dberkholz@gentoo.org> 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 unsupported archive format, unpack just does nothing. This isn't a
good default behaviour; if a package really wants something to be
ignored silently, it should have to say so.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Donnie Berkholz]

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

On 22:53 Mon 09 Mar     , Ciaran McCreesh wrote:
> On Mon, 9 Mar 2009 15:39:41 -0700
> Donnie Berkholz <dberkholz@gentoo.org> 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 unsupported archive format, unpack just does nothing. This isn't a
> good default behaviour; if a package really wants something to be
> ignored silently, it should have to say so.

I like it when unpack ${A} works regardless of what's in SRC_URI, 
especially if it's an uncompressed file rather than an unsupported 
compression format.

-- 
Thanks,
Donnie

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

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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Ciaran McCreesh]

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

On Thu, 12 Mar 2009 11:43:58 -0700
Donnie Berkholz <dberkholz@gentoo.org> 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 silently, it should have to say so.
> 
> I like it when unpack ${A} works regardless of what's in SRC_URI, 
> especially if it's an uncompressed file rather than an unsupported 
> compression format.

You'd have to do unpack --if-compressed ${A} to get that behaviour.
It's sometimes handy to have, and of course it's necessary for
default_src_unpack, but silently ignoring duff inputs isn't very
Unixy or very software engineeringy...

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Michael Haubenwallner]

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 splatting).
> 
> Sounds useful to have less '|| die' all over the place.

Whats wrong with 'set -e' and doing '|| true' behind?
IMO this would feel more shell-ish.

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Ciaran McCreesh]

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

On Tue, 10 Mar 2009 10:08:06 +0100
Michael Haubenwallner <haubi@gentoo.org> wrote:
> Whats wrong with 'set -e' and doing '|| true' behind?

Waaaaaaay too many false positives.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Peter Alfredsen]

On Mon, 9 Mar 2009 20:26:24 +0000
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> 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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Sébastien Fabbro]

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

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 recipe, a bit like the emacs testing
plans. It could be useful for arch testers, guis, and revdep tests.
It would force packagers to define an omitted src_test when upstream
actually had one.
 
As mentioned by Christian, src_test is desirable in sci
packages to get consistent results, but sci packages depend on lots of
others, so you can't limit tests to some categories. And yes, you can't
revdep test everything, but you can reduce bug load.

It seems to be controversial, so unfortunately does not look like a good
candidate for a flash EAPI upgrade. But really, don't dismiss it just
because your pet package doesn't pass tests or it takes too long. One
solution for packages taking too long to compile is not dismissing
tests but a good binary package system.

-- 
Sébastien

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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Doug Goldstein]

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

On Mon, Mar 9, 2009 at 3:26 PM, Ciaran McCreesh <
ciaran.mccreesh@googlemail.com> wrote:

> On Sun, 08 Mar 2009 08:49:16 +0100
> Tiziano Müller <dev-zero@gentoo.org> 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)


+1 from  me

>
>
> * DEFINED_PHASES must be supported (ditto)


+1 from me

>
>
> Next, some probably easy but long standing features:
>
> * src_test run unless RESTRICTed or explicitly disabled by the user (bug
>  184812)


I'd love to but please look at the most recent comment I've made on the bug

>
>
> * have econf run ./configure with --disable-dependency-tracking and
>  --enable-fast-install (bug 211529)


+1 from me. Did we ever test autoconf 2.13 based stuff?

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


definitely +1 from me. I've been trying to put kernel_linux and such in my
ebuilds already to improve this.

>
>
> Some things we should probably sort out:
>
> * The list of extensions for unpack probably needs a couple of new
>  things.


We also need a way for the actual program being used for the unpack to be
added to DEPEND.

>
>
> * Provide ebuilds a way to differentiate between updates and removals
>  (bug 205557), since the way devmanual says to do it got broken by a
>  non-EAPIed change. This one's slightly trickier than initially
>  apparent, because a solution's needed for the weird cases. One
>  example is if you have foo-1:1 and foo-2:2 installed, and you're
>  installing foo-2:1. In this case, it's both a reinstall and an
>  upgrade. One possibility is a REPLACING_VERSIONS variable that
>  contains a list of all versions being replaced, along with a
>  REPLACED_BY_VERSION variable for the pre/postrm part.


+1 from me

>
>
> Not sure if these can go in in time for Portage or not:
>
> * 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 splatting).


+1 from me

>
>
> * Calling unpack on an unrecognised extension should be fatal, unless
>  --if-compressed is specified. The default src_unpack needs to use
>  this.


+1 from me

>
>
> * pkg_info should work on things that aren't installed, as well as
>  things that are.


We'd need to properly educate people about this because I'm pretty sure a
bunch of pkg_info()'s require the actual package to be installed currently.

>
>
> --
> Ciaran McCreesh
>

[-- Attachment #2: Type: text/html, Size: 5103 bytes --]

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Jeremy Olexa]

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 distinct
> improvements:

I'm replying to the top level because I don't think any of the ideas are 
particularly bad. However, I wanted to raise this point:

Should the next EAPI (as proposed) be a major "release" in terms of 
naming? And should it really be adding features? It is my opinion that 
EAPI bumps should move slower, one every year or so, in order to 
preserve upgradeable options for people that don't update often. 
However, I'm not going to let my opinion here block progress if it is 
needed.

I would propose that EAPI="2.1" be an extension of EAPI="2" and be 
limited to only bug fixes as presented instead of smashing the bug fixes 
in EAPI="3" along with new features.

With that said, can't bug fixes be implemented without an EAPI bump? I 
suppose that is not exactly safe in all cases.. =/ But, we should do a 
better job fixing "bugs" while the EAPI is in ~arch still. No, I don't 
have any ideas on how to accomplish that.. =P

(Don't let this post turn into bikeshedding wrt naming options, just 
throwing it out there without wanting to defend it too much)

-Jeremy

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Ciaran McCreesh]

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

On Mon, 09 Mar 2009 17:38:51 -0500
Jeremy Olexa <darkside@gentoo.org> 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 see, the main driving force behind all of this
is the immediate need for [use(+)] deps (since developers don't want to
have to mess around with complex || statements), and [use(+)] is most
definitely a new feature.

> With that said, can't bug fixes be implemented without an EAPI bump?

If we screw up the specification and catch it early enough on, then
yes. But [use(+)] really isn't a bug fix...

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Ciaran McCreesh]

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

On Sun, 08 Mar 2009 08:49:16 +0100
Tiziano Müller <dev-zero@gentoo.org> 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 consider:

If S= is wrong (which it often is, for packages with icky tarballs),
src_configure and src_compile won't error out. These days this isn't a
huge deal, because your custom src_install will probably fail. But if
we're introducing a default src_install, it will instead see no
Makefile and just do nothing, resulting in an empty package being
installed.

Currently, at the start of src_configure, the package manager does a cd
to ${S} if ${S} exists, and to ${WORKDIR} otherwise. I'd like to
propose that ${S} not existing should instead be an error if either of
the following conditions are met:

* ${A} is non-empty
* Any of src_unpack, src_configure, src_compile or src_install is a
  defined phase.

Ebuilds where this would trigger a false positive would have to specify
S=${WORKDIR}.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Maciej Mrozowski]

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

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)
# <global_use_flag> - <alias1> <alias2> ...
xml - libxml2

example - use.local.aliases: (more real-world scenario)
# <local_use_flag> - <alias1> <alias2> ...
dev-libs/soprano:sesame2 - java
media-video/transcode:dvdread - dvd

-- 
regards
MM



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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Ciaran McCreesh]

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

On Fri, 13 Mar 2009 00:05:54 +0100
Maciej Mrozowski <reavertm@poczta.fm> 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 overlays, get
very messy. Working out exactly what happens when aliases disappear or
are inconsistent gets to be rather tricky.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Ciaran McCreesh]

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

On Sun, 08 Mar 2009 08:49:16 +0100
Tiziano Müller <dev-zero@gentoo.org> 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 useful.

* Kill off KV. This should be eclass territory.

* Ban dohtml, which is weird, and add '-u dir' to dodoc, so you
  can use dodoc -r -u html blah instead.

* We currently have .xz / .tar.xz support for unpack down for EAPI 3.
  Am I right in thinking there's nothing stable that can handle .xz
  files?

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Tiziano Müller]

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

Am Freitag, den 13.03.2009, 20:11 +0000 schrieb Ciaran McCreesh:
> On Sun, 08 Mar 2009 08:49:16 +0100
> Tiziano Müller <dev-zero@gentoo.org> 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 useful.
Never used it, thus ++

> 
> * Kill off KV. This should be eclass territory.
++

> 
> * Ban dohtml, which is weird, and add '-u dir' to dodoc, so you
>   can use dodoc -r -u html blah instead.
But then we shouldn't introduce doexample, but use "dodoc -r -u
examples" instead.
I liked that dohtml can filter based on file endings, this made it in
the past easier to install html docs.
So, if we could have something like:
  filter_files -t web docs/ | dodoc -r -u html
that would be fine :-)

> 
> * We currently have .xz / .tar.xz support for unpack down for EAPI 3.
>   Am I right in thinking there's nothing stable that can handle .xz
>   files?
> 
As far as I know, but vapier is probably the expert here.



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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Mart Raudsepp]

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

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 it's time for a short eapi bump with some distinct
> improvements:
> 
> http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ
> 
> 
> Please discuss.


Sorry for getting my points of discussion on the details to the list so
late.
I have covered some of my concerns on the items in meetings and
otherwise on IRC, but now I'll try to get to them in further detail and
better wording to the mailing list.

I'm going to go item-by-item here for the things I don't expect much
replies to, and then starting separate threads for those that I do.


pkg_pretend
===========

No objections.
Gives an intermediate step for handling USE flag combination
incompatibilities at pretend stage (to not find it failed in the
morning), yet has uses outside that as well. So, once there is a way to
express those kind of USE flag dependencies outside of pkg_pretend in a
better way in a future EAPI, pkg_pretend will still be useful for other
(less common) cases and can provide a description of the problem to the
user.


Use based deps with non-existing USE flags
==========================================

No objections.
Implements the missing bit of "built_with_use --missing"
Main driving force behind EAPI-3.


default src_install
===================

No considerable input yet, catching up with the latest thread about
src_install bikeshedding


doinclude
=========

Unnecessary. Might be interesting for automatic executable permission
removing, but upstream build systems should be fixed instead for such a
big and rare error.


ban dosed
=========

I don't exactly see a reason for the banning yet, but no objections due
to general agreement on it and having no technical objections


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?


unpack failing on unknown types
===============================

Uncertain about it's worthiness. Might rather have the opposite with a
--strict argument kind of deal. No official objection from me.


docompress
==========

Need some more time to digest through it in relation to
PORTAGE_COMPRESS, prepalldocs and co. Will try to follow-up before
meeting.


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.


DEFINED_PHASES must be supported (and cached properly)
======================================================

No opinion, up to the package manager developers more or less.
Not sure why this needs to be an EAPI item. Hard to see a use case for
the variable being available for ebuild usage for it to be necessary to
be an EAPI item.
By my understanding it is (also?) a required implementation detail to
handle pkg_pretend sanely and with minimal time hit.


Limit values in $USE to ones in $IUSE:
======================================

Seems more of a QA test, but forcing it can make it be caught at start.
Don't see why it must be an EAPI item. Just vet the tree of (future?)
repoman warnings about it and make it happen for
all EAPIs. Impact on overlays is minimal because it is a QA error to not
define them and they get what they asked for.

Not strongly opposed to it being in the EAPI.


--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 slightly inappropriate, given the
above.
Don't think this is an item for fast-tracked EAPI-3.


utility commands should die by default
======================================

Would like to see a list of those utility commands that would be made to
die by default.


ban || ( foo? ( . ) . )
=======================

It is not the business of an EAPI to start disallowing *DEPEND string
constructs.
There is no useful alternative provided yet to my knowledge and this is
really a QA issue, not an EAPI issue.
Not convinced on the sub-optimal use case being the only one, either.

Strongly objecting on the grounds that it is not something that should
be an EAPI issue.


unpack has to handle more types
===============================

Would be nice to get a QA warning when unpacking .lzma, .xz, etc that
need a build depend for the unpacker and don't have it yet. Then sounds
fine.



In separate threads:
* Slot operator support
* dohard being deprecated


Did I miss anything?
I'm not even sure anymore where to find a list of items that is current
for what's on the table for EAPI-3 right now...

-- 
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] Ideas for a (fast) EAPI=3

[Mart Raudsepp]

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

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, and it is fixed now.

However due to technical restriction intrinsic to hard links, we should
rephrase what it does - to emphasize that it tries to do a hard link,
but if that is not technically possible, it will be a copy. That is,
there is no guarantee but a best effort.

It can be useful when it works. If it ends up in a separate partition,
there is nothing we can do. But the common case is that the hard link
destination is in the same directory as the source, and that pretty much
means the same partition as well.


-- 
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] Ideas for a (fast) EAPI=3

[Olivier Crête]

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

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 slightly inappropriate, given the
> above.
> Don't think this is an item for fast-tracked EAPI-3.

I'm not a big fan either of this one either, when stuff is patched, you
may not want that disabled.

-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer

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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Tiziano Müller]

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

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
> > 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:
> > 
> > http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ
> > 
> > 
> > Please discuss.
> 
> 
> Sorry for getting my points of discussion on the details to the list so
> late.
> I have covered some of my concerns on the items in meetings and
> otherwise on IRC, but now I'll try to get to them in further detail and
> better wording to the mailing list.
> 
> I'm going to go item-by-item here for the things I don't expect much
> replies to, and then starting separate threads for those that I do.
> 
> 
> pkg_pretend
> ===========
> 
> No objections.
> Gives an intermediate step for handling USE flag combination
> incompatibilities at pretend stage (to not find it failed in the
> morning), yet has uses outside that as well. So, once there is a way to
> express those kind of USE flag dependencies outside of pkg_pretend in a
> better way in a future EAPI, pkg_pretend will still be useful for other
> (less common) cases and can provide a description of the problem to the
> user.
> 
> 
> Use based deps with non-existing USE flags
> ==========================================
> 
> No objections.
> Implements the missing bit of "built_with_use --missing"
> Main driving force behind EAPI-3.
> 
> 
> default src_install
> ===================
> 
> No considerable input yet, catching up with the latest thread about
> src_install bikeshedding
> 
> 
> doinclude
> =========
> 
> Unnecessary. Might be interesting for automatic executable permission
> removing, but upstream build systems should be fixed instead for such a
> big and rare error.
> 
> 
> ban dosed
> =========
> 
> I don't exactly see a reason for the banning yet, but no objections due
> to general agreement on it and having no technical objections
> 
> 
> 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?
> 
> 
> unpack failing on unknown types
> ===============================
> 
> Uncertain about it's worthiness. Might rather have the opposite with a
> --strict argument kind of deal. No official objection from me.
> 
> 
> docompress
> ==========
> 
> Need some more time to digest through it in relation to
> PORTAGE_COMPRESS, prepalldocs and co. Will try to follow-up before
> meeting.
> 
> 
> 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.

The metadata cache needs to be specified to make it work with compliant
PM's and is therefore a part of the PMS.
A change is therefore required to be done on a per-EAPI base.

> 
> 
> DEFINED_PHASES must be supported (and cached properly)
> ======================================================
> 
> No opinion, up to the package manager developers more or less.
> Not sure why this needs to be an EAPI item. Hard to see a use case for
> the variable being available for ebuild usage for it to be necessary to
> be an EAPI item.
> By my understanding it is (also?) a required implementation detail to
> handle pkg_pretend sanely and with minimal time hit.
> 
> 
> Limit values in $USE to ones in $IUSE:
> ======================================
> 
> Seems more of a QA test, but forcing it can make it be caught at start.
> Don't see why it must be an EAPI item. Just vet the tree of (future?)
> repoman warnings about it and make it happen for
> all EAPIs. Impact on overlays is minimal because it is a QA error to not
> define them and they get what they asked for.
> 
> Not strongly opposed to it being in the EAPI.
> 
Why it has to be done in an EAPI: It matters whether you have to put for
example userland_GNU in IUSE if you want to use it in the ebuild or not.


> 
> --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 slightly inappropriate, given the
> above.
> Don't think this is an item for fast-tracked EAPI-3.

custom configure scripts mostly already break with econf, so not an
issue.

> 
> 
> utility commands should die by default
> ======================================
> 
> Would like to see a list of those utility commands that would be made to
> die by default.
basically all do* commands.

> 
> 
> ban || ( foo? ( . ) . )
> =======================
> 
> It is not the business of an EAPI to start disallowing *DEPEND string
> constructs.
It's EAPI's business to define what's valid and what is not.

> There is no useful alternative provided yet to my knowledge and this is
> really a QA issue, not an EAPI issue.
The problem is that there is no valid use case to justify the existence
of this construct. In either way users will most likely not have what
they want if "|| ( foo? ( . ) . )" is being used. Disallowing it will
therefore help the user to get what the specified and is therefore a
good thing.

> Not convinced on the sub-optimal use case being the only one, either.
> 
> Strongly objecting on the grounds that it is not something that should
> be an EAPI issue.
> 
> 
> unpack has to handle more types
> ===============================
> 
> Would be nice to get a QA warning when unpacking .lzma, .xz, etc that
> need a build depend for the unpacker and don't have it yet. Then sounds
> fine.
But you don't want unpack fail on unknown types? Seems a bit
inconsequent.

> 
> 
> 
> In separate threads:
> * Slot operator support
> * dohard being deprecated
> 
> 
> Did I miss anything?
> I'm not even sure anymore where to find a list of items that is current
> for what's on the table for EAPI-3 right now...
> 
The PMS. (just do "emerge pms" for an up-to-date version).


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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Mart Raudsepp]

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

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.
> 
> The metadata cache needs to be specified to make it work with
> compliant
> PM's and is therefore a part of the PMS.
> A change is therefore required to be done on a per-EAPI base.

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.
Anyhow, if zmedico is cool with it, I'm cool.

> > Limit values in $USE to ones in $IUSE:
> > ======================================
> > 
> > Seems more of a QA test, but forcing it can make it be caught at
> start.
> > Don't see why it must be an EAPI item. Just vet the tree of
> (future?)
> > repoman warnings about it and make it happen for
> > all EAPIs. Impact on overlays is minimal because it is a QA error to
> not
> > define them and they get what they asked for.
> > 
> > Not strongly opposed to it being in the EAPI.
> > 
> Why it has to be done in an EAPI: It matters whether you have to put
> for
> example userland_GNU in IUSE if you want to use it in the ebuild or
> not.

I don't think I want to have to specify userland_GNU and co in IUSE.
They aren't USE flags that get set by the user, so having to put them in
IUSE isn't intuitive either.

> 
> > 
> > --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 slightly inappropriate, given the
> > above.
> > Don't think this is an item for fast-tracked EAPI-3.
> 
> custom configure scripts mostly already break with econf, so not an
> issue.

Some might accept all current switches we pass with econf, but not
--disable-dependency-tracking.
Maybe if there's a way to opt out of the --disable-dependency-tracking
when necessary... the unlikely need for that will get seen by the
maintainer when he/she upgrades the ebuild to EAPI-3.
econf is a complex and long (many arguments passed) beast to replicate
just without --disable-dependency-tracking

> > ban || ( foo? ( . ) . )
> > =======================
> > 
> > It is not the business of an EAPI to start disallowing *DEPEND
> string
> > constructs.
> It's EAPI's business to define what's valid and what is not.

We disagree there. Things should be an EAPI item when it is reasonably
required to be. In this case a simple repoman warning on such a
construct suffices.

> > There is no useful alternative provided yet to my knowledge and this
> is
> > really a QA issue, not an EAPI issue.
> The problem is that there is no valid use case to justify the
> existence
> of this construct. In either way users will most likely not have what
> they want if "|| ( foo? ( . ) . )" is being used. Disallowing it will
> therefore help the user to get what the specified and is therefore a
> good thing.

Then we should disallow all constructs that currently give a repoman
warning as well?
It is a QA issue to me, not something to overload an EAPI with.
QA warning for all EAPI's.

> > Not convinced on the sub-optimal use case being the only one,
> either.
> > 
> > Strongly objecting on the grounds that it is not something that
> should
> > be an EAPI issue.
> > 
> > 
> > unpack has to handle more types
> > ===============================
> > 
> > Would be nice to get a QA warning when unpacking .lzma, .xz, etc
> that
> > need a build depend for the unpacker and don't have it yet. Then
> sounds
> > fine.
> But you don't want unpack fail on unknown types? Seems a bit
> inconsequent.

Unknown types in this case is about "not packed at all".
Or we could define those types - .patch, .bin, etc
PM knows that there's .lzma, .xz and so on, so it could know which
build-time deps are necessary - repoman warning anyhow, later some
alternative unpacker might surface.

> > Did I miss anything?
> > I'm not even sure anymore where to find a list of items that is
> current
> > for what's on the table for EAPI-3 right now...
> > 
> The PMS. (just do "emerge pms" for an up-to-date version).

that's a bit complicated with not having texlive installed anywhere
yet...



-- 
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] Ideas for a (fast) EAPI=3

[Ciaran McCreesh]

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

On Thu, 09 Apr 2009 13:44:55 +0300
Mart Raudsepp <leio@gentoo.org> 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 have to specify userland_GNU and co in IUSE.
> They aren't USE flags that get set by the user, so having to put them
> in IUSE isn't intuitive either.

And with the proposal as currently worded, you don't have to. The
profiles do that magically for you.

> Some might accept all current switches we pass with econf, but not
> --disable-dependency-tracking.

'might'? Have you found any? Given the mess econf currently passes, it
strikes me as highly unlikely.

> Then we should disallow all constructs that currently give a repoman
> warning as well?

We should disallow constructs that can't be used correctly, if allowing
them is a significant burden on the package manager.

> Unknown types in this case is about "not packed at all".
> Or we could define those types - .patch, .bin, etc
> PM knows that there's .lzma, .xz and so on, so it could know which
> build-time deps are necessary - repoman warning anyhow, later some
> alternative unpacker might surface.

Uh. Unknown types doesn't mean "fail on lzma if lzma's not installed".
Please check the PMS draft for what it does mean.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Ciaran McCreesh]

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

On Thu, 09 Apr 2009 04:51:06 +0300
Mart Raudsepp <leio@gentoo.org> 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?

The PMS draft explains it. It's simple, though: currently, doins on a
symlink does something arbitrary. We want it to install the symlink.

> unpack failing on unknown types
> ===============================
> 
> Uncertain about it's worthiness. Might rather have the opposite with a
> --strict argument kind of deal. No official objection from me.

What with the moving towards auto-die, the trend is towards "strict
unless explicitly told not to be".

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

The cache format's tied to EAPI in a fairly unpleasant manner. It's a
necessary evil.

> DEFINED_PHASES must be supported (and cached properly)
> ======================================================
> 
> No opinion, up to the package manager developers more or less.
> Not sure why this needs to be an EAPI item. Hard to see a use case for
> the variable being available for ebuild usage for it to be necessary
> to be an EAPI item.

DEFINED_PHASES isn't available to the ebuild. But it is in the metadata
cache, which PMS has to cover.

> By my understanding it is (also?) a required implementation detail to
> handle pkg_pretend sanely and with minimal time hit.

Correct. Without it there's a delay of ~0.1s per ebuild in the
resolution set at pretend time, which soon adds up for certain
reasonably common use cases.

> Limit values in $USE to ones in $IUSE:
> ======================================
> 
> Seems more of a QA test, but forcing it can make it be caught at
> start. Don't see why it must be an EAPI item. Just vet the tree of
> (future?) repoman warnings about it and make it happen for
> all EAPIs. Impact on overlays is minimal because it is a QA error to
> not define them and they get what they asked for.

It needs to be in EAPI because we're talking about changing how the
ebuild environment is specified. Also, repoman can't catch most
accidental abuses of this.

> --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 slightly inappropriate, given the
> above.

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 see any examples provided.

> utility commands should die by default
> ======================================
> 
> Would like to see a list of those utility commands that would be made
> to die by default.

The PMS draft has one.

> ban || ( foo? ( . ) . )
> =======================
> 
> It is not the business of an EAPI to start disallowing *DEPEND string
> constructs.
> There is no useful alternative provided yet to my knowledge and this
> is really a QA issue, not an EAPI issue.

There is no use case for the construct anyway.

> Not convinced on the sub-optimal use case being the only one, either.
> 
> Strongly objecting on the grounds that it is not something that should
> be an EAPI issue.

Behaviour of || ( foo? ( . ) ) is already an EAPI issue, and has a
horrible section of PMS devoted to explaining its quirky behaviour.

> I'm not even sure anymore where to find a list of items that is
> current for what's on the table for EAPI-3 right now...

Do a git log on the PMS draft (or look at the summary table in the
appendix). It's fairly close to one commit per EAPI item.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

[Peter Volkov]

В Чтв, 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 see any examples provided.

Only one package fail completely here: dev-libs/elfutils. But there are
much more packages which does not fail but issue warning about
unsupported option.

-- 
Peter.