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.

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

[Ciaran McCreesh]

On Thu, 09 Apr 2009 13:44:55 +0300
Mart Raudsepp  wrote:
> But the metadata cache isn't per-EAPI in the sense of multiple
> metadata caches, one for each EAPI. There might be per-EAPI metadata
> cache items though.

The cache format is per-EAPI, with a degree of overlap.

> I don't think I want to 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


signature.asc
Description: PGP signature

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

[Ciaran McCreesh]

On Thu, 09 Apr 2009 04:51:06 +0300
Mart Raudsepp  wrote:
> doins support for symlinks
> ==
> 
> Lacking information. Need to see if the PMS draft has anything about
> it. The bug and summaries just talk about the support, but no
> details. Would it be an argument to doins?

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


signature.asc
Description: PGP signature

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

[Mart Raudsepp]

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: l...@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio


signature.asc
Description: This is a digitally signed message part

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

[Tiziano Müller]

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? ( . ) . )
> =

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

[Olivier Crête]

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
tes...@gentoo.org
Gentoo Developer


signature.asc
Description: This is a digitally signed message part

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

[Mart Raudsepp]

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: l...@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio


signature.asc
Description: This is a digitally signed message part

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

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


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 E

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

[Tiziano Müller]

Am Freitag, den 13.03.2009, 20:11 + schrieb Ciaran McCreesh:
> On Sun, 08 Mar 2009 08:49:16 +0100
> Tiziano Müller  wrote:
> > So I think it's time for a short eapi bump with some distinct
> > improvements:
> 
> Some more small candidates to discuss:
> 
> * How would people feel about killing 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.




signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

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

[Ciaran McCreesh]

On Sun, 08 Mar 2009 08:49:16 +0100
Tiziano Müller  wrote:
> So I think it's time for a short eapi bump with some distinct
> improvements:

Some more small candidates to discuss:

* How would people feel about killing 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


signature.asc
Description: PGP signature

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

[Ciaran McCreesh]

On Fri, 13 Mar 2009 00:05:54 +0100
Maciej Mrozowski  wrote:
> No idea whether it's "fast" idea, but:
> 
> - USE flags aliases

Aliases for anything aren't fast or easy.

The big problem is this: the interactions between installed packages and
the main repository, and between the main repository and overlays, get
very messy. Working out exactly what happens when aliases disappear or
are inconsistent gets to be rather tricky.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

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

[Maciej Mrozowski]

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

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

-- 
regards
MM




signature.asc
Description: This is a digitally signed message part.

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

[Ciaran McCreesh]

On Thu, 12 Mar 2009 11:43:58 -0700
Donnie Berkholz  wrote:
> > Currently, if a package does an explicit 'unpack foo.bar',
> > where .bar is an unsupported archive format, unpack just does
> > nothing. This isn't a good default behaviour; if a package really
> > wants something to be ignored 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


signature.asc
Description: PGP signature

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

[Donnie Berkholz]

On 22:53 Mon 09 Mar , Ciaran McCreesh wrote:
> On Mon, 9 Mar 2009 15:39:41 -0700
> Donnie Berkholz  wrote:
> > > * Calling unpack on an unrecognised extension should be fatal,
> > > unless --if-compressed is specified. The default src_unpack needs
> > > to use this.
> > 
> > Why?
> 
> Currently, 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


pgpHnu7zpMu45.pgp
Description: PGP signature

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

[Doug Goldstein]

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

> On Sun, 08 Mar 2009 08:49:16 +0100
> Tiziano Müller  wrote:
> > http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ
>
> Here're some more easy ones.
>
> First up, un-optionaling some optional 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
>

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

[Sébastien Fabbro]

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


signature.asc
Description: PGP signature

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

[Ciaran McCreesh]

On Sun, 08 Mar 2009 08:49:16 +0100
Tiziano Müller  wrote:
> With eapis 1 and 2 we introduced nice features but also a couple of
> new problems. One of them are the use dependencies when the package
> you depend on doesn't have the use flag anymore (see [1] for an
> example).

Here's another one to 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


signature.asc
Description: PGP signature

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

[Ciaran McCreesh]

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

Waaay too many false positives.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

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]

On Mon, 09 Mar 2009 17:38:51 -0500
Jeremy Olexa  wrote:
> Should the next EAPI (as proposed) be a major "release" in terms of 
> naming?

We don't use major.minor numbers for EAPI or have a concept like that.
It's too much mess.

> And should it really be adding features?

Well... So far as I can 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


signature.asc
Description: PGP signature

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

[Ciaran McCreesh]

On Mon, 9 Mar 2009 15:39:41 -0700
Donnie Berkholz  wrote:
> > * Calling unpack on an unrecognised extension should be fatal,
> > unless --if-compressed is specified. The default src_unpack needs
> > to use this.
> 
> Why?

Currently, if a package does an explicit 'unpack foo.bar', where .bar is
an 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


signature.asc
Description: PGP signature

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

[Peter Alfredsen]

On Mon, 9 Mar 2009 20:26:24 +
Ciaran McCreesh  wrote:

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

This one is not uncontroversial and will not go in a 'quick' EAPI I
think.

/loki_val

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

[Donnie Berkholz]

On 20:26 Mon 09 Mar , Ciaran McCreesh wrote:
> On Sun, 08 Mar 2009 08:49:16 +0100
> Tiziano Müller  wrote:
> > http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ
> 
> Here're some more easy ones.

This list sounds mostly good to me.

> * Limit values in $USE to ones in $IUSE (bug 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


pgplbqZtuOmBU.pgp
Description: PGP signature

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

[Ciaran McCreesh]

On Mon, 09 Mar 2009 14:28:48 -0700
Zac Medico  wrote:
> > If we must do that... Can we get something in profiles a bit like
> > this:
> > 
> > USE_EXPAND_IMPLICIT="USERLAND KERNEL ELIBC ARCH"
> > USE_EXPAND_UNPREFIXED="ARCH"
> > USE_EXPAND_VALUES_USERLAND="GNU freebsd"
> > USE_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


signature.asc
Description: PGP signature

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

On Mon, 09 Mar 2009 13:56:19 -0700
Zac Medico  wrote:
> Ciaran McCreesh wrote:
> > * Limit values in $USE to ones in $IUSE (bug 176467). The existing
> >   behaviour's majorly annoying; time for the package manager to
> > start enforcing things strictly.
> 
> My impression is that most ebuild 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


signature.asc
Description: PGP signature

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]

On Sun, 08 Mar 2009 08:49:16 +0100
Tiziano Müller  wrote:
> http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ

Here're some more easy ones.

First up, un-optionaling some optional things. No impact for developers:

* PROPERTIES must be cached properly (it's optional in current EAPIs)

* 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


signature.asc
Description: PGP signature

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

[Tobias Scherbaum]

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


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

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

[Tiziano Müller]

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.



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

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

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

-- 
Thanks,
Donnie

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


pgpD63RqCvGov.pgp
Description: PGP signature

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

[Donnie Berkholz]

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


pgpN1K1VVp0pJ.pgp
Description: PGP signature

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

[Thomas Anderson]

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
-


pgp4mn7bM5lm2.pgp
Description: PGP signature

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

[Tiziano Müller]

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.




signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

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

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

-- 
Thanks,
Donnie

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


pgpEIwaNLiQmh.pgp
Description: PGP signature

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

[Donnie Berkholz]

On 19:35 Sun 08 Mar , Tiziano Müller wrote:
> Am Sonntag, den 08.03.2009, 11:24 -0700 schrieb Donnie Berkholz:
> > On 10:01 Sun 08 Mar , Donnie Berkholz wrote:
> > > On 16:48 Sun 08 Mar , Ciaran McCreesh wrote:
> > > > On Sun, 8 Mar 2009 09:42:29 -0700
> > > > Donnie Berkholz  wrote:
> > > > > - 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


pgpijeydm3D5W.pgp
Description: PGP signature

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

[Tiziano Müller]

Am Sonntag, den 08.03.2009, 11:24 -0700 schrieb Donnie Berkholz:
> On 10:01 Sun 08 Mar , Donnie Berkholz wrote:
> > On 16:48 Sun 08 Mar , Ciaran McCreesh wrote:
> > > On Sun, 8 Mar 2009 09:42:29 -0700
> > > Donnie Berkholz  wrote:
> > > > - I understand the reasoning for the SRC_CONFIGURE_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?)



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

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

[Tiziano Müller]

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



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

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

[Tiziano Müller]

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

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



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

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

[Tiziano Müller]

Am Sonntag, den 08.03.2009, 10:01 -0700 schrieb Donnie Berkholz:
> On 16:48 Sun 08 Mar , Ciaran McCreesh wrote:
> > On Sun, 8 Mar 2009 09:42:29 -0700
> > Donnie Berkholz  wrote:
> > > - I understand the reasoning for the SRC_CONFIGURE_WITH blah stuff. I 
> > > strongly oppose this 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="...")



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

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

[Donnie Berkholz]

On 10:01 Sun 08 Mar , Donnie Berkholz wrote:
> On 16:48 Sun 08 Mar , Ciaran McCreesh wrote:
> > On Sun, 8 Mar 2009 09:42:29 -0700
> > Donnie Berkholz  wrote:
> > > - I understand the reasoning for the SRC_CONFIGURE_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


pgpx0EF3mG45G.pgp
Description: PGP signature

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

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

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



signature.asc
Description: This is a digitally signed message part

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

[Ciaran McCreesh]

On Sun, 08 Mar 2009 12:50:19 -0430
Jesus Rivero  wrote:
> ~if python-2.6 is the selected interpreter and it misses the tk
> use flag. Is there a way to workaround this? am I missing something?
> or is just something else
> ~to take into account for next eapi?

Fixing this mess properly 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


signature.asc
Description: PGP signature

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

[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

[Donnie Berkholz]

On 16:48 Sun 08 Mar , Ciaran McCreesh wrote:
> On Sun, 8 Mar 2009 09:42:29 -0700
> Donnie Berkholz  wrote:
> > - I understand the reasoning for the SRC_CONFIGURE_WITH blah stuff. I 
> > strongly oppose this 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


pgpnd1Ie6CDqQ.pgp
Description: PGP signature

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

[Ciaran McCreesh]

On Sun, 8 Mar 2009 09:42:29 -0700
Donnie Berkholz  wrote:
> - I understand the reasoning for the SRC_CONFIGURE_WITH blah stuff. I 
> strongly oppose this implementation because it makes ebuilds less
> like bash scripts that are easy to understand. Instead I suggest
> extending use_with() and use_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


signature.asc
Description: PGP signature

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

[Donnie Berkholz]

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


pgpm0J8uQhoXG.pgp
Description: PGP signature

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

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


signature.asc
Description: This is a digitally signed message part.

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

[Tiziano Müller]

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



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

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

[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"
^^^

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

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.

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

[Tiziano Müller]

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.



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

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

[Ciaran McCreesh]

On Sun, 08 Mar 2009 00:08:37 -0800
Josh Saddler  wrote:
> Is there a reason why we should ram through a new EAPI for something
> that *looks* like another "Paludis supports this so let's make it a
> Portage standard" proposal? Is there some kind of time deadline here
> that you all want?

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


signature.asc
Description: PGP signature

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

[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? Is there some kind of time deadline here
that you all want?

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




signature.asc
Description: OpenPGP digital signature

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

[Tiziano Müller]

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 [...]"



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil