[gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Tomáš Chvátal]

Resending as i sent it from gmail instead of google acc so it didn't
hit the list.


---------- Přeposlaná zpráva ----------
Od: Tomáš Chvátal <tomas.chvatal@gmail.com>
Datum: 5. září 2011 18:08
Předmět: Re: [gentoo-dev-announce] Call for items for September 13
council meeting
Komu: gentoo-dev@lists.gentoo.org


Start collecting ideas for EAPI5.

I myself would like PATCHES array to be default in src_prepare phase
and some solution for runtime optional deps, Instead of elog in
postinst something like Recommended from rpm.

Cheers

Tom

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Andreas K. Hüttel]

Ack.. both makes definitely sense.



> ---------- Přeposlaná zpráva ----------
> Od: Tomáš Chvátal <tomas.chvatal@gmail.com>
> Datum: 5. září 2011 18:08
> Předmět: Re: [gentoo-dev-announce] Call for items for September 13
> council meeting
> Komu: gentoo-dev@lists.gentoo.org
> 
> 
> Start collecting ideas for EAPI5.
> 
> I myself would like PATCHES array to be default in src_prepare phase
> and some solution for runtime optional deps, Instead of elog in
> postinst something like Recommended from rpm.
> 
> Cheers
> 
> Tom

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Ulrich Mueller]

>>>>> On Wed, 7 Sep 2011, Tomáš Chvátal wrote:

> Start collecting ideas for EAPI5.

I suggest that EAPI 5 should include the two features that have been
omitted from EAPI 4 [1,2].

Apart from this, I think we should be more careful for the next EAPI,
in order to avoid such long delays as we had with EAPI 4. One possible
solution would be to only accept features where a preliminary
implementation in Portage is available.

> I myself would like PATCHES array to be default in src_prepare phase
> and some solution for runtime optional deps, Instead of elog in
> postinst something like Recommended from rpm.

Looks reasonable (if an implementation is ready). Although I don't
understand how it is related to rpm.

Ulrich

[1] <http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=9d2b8ee57bf3be941cfdfe13650952d91b9edfdc>
[2] <http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=409fccc10861c361f37a959195d7581a5c376dd9>

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Tomáš Chvátal]

2011/9/7 Ulrich Mueller <ulm@gentoo.org>:
>>>>>> On Wed, 7 Sep 2011, Tomáš Chvátal wrote:
>
>> Start collecting ideas for EAPI5.
>
> I suggest that EAPI 5 should include the two features that have been
> omitted from EAPI 4 [1,2].
>
> Apart from this, I think we should be more careful for the next EAPI,
> in order to avoid such long delays as we had with EAPI 4. One possible
> solution would be to only accept features where a preliminary
> implementation in Portage is available.
Agreed the wait last time was really bad.
>
>> I myself would like PATCHES array to be default in src_prepare phase
>> and some solution for runtime optional deps, Instead of elog in
>> postinst something like Recommended from rpm.
>
> Looks reasonable (if an implementation is ready). Although I don't
> understand how it is related to rpm.

Well the patches code is in base eclass.

For Recommended it works like this:
blabla.spec
Recommended: xf86-video-ati

zypper in blabla
...
You might consider installing these additional packages:
     xf86-video-ati


It for sure needs more thinking as this is just basic idea. It might
even take into account that if you install the recommended patckage
with oneshot it should not be depcleaned unless all recommending
packages are gone too, and so on.

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Michał Górny]

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

On Wed, 7 Sep 2011 16:27:01 +0200
Tomáš Chvátal <scarabeus@gentoo.org> wrote:

> Well the patches code is in base eclass.

Then you should first consider moving epatch to PMS. I'd honestly
prefer going the other way.

> For Recommended it works like this:
> blabla.spec
> Recommended: xf86-video-ati
> 
> zypper in blabla
> ...
> You might consider installing these additional packages:
>      xf86-video-ati
> 
> 
> It for sure needs more thinking as this is just basic idea. It might
> even take into account that if you install the recommended patckage
> with oneshot it should not be depcleaned unless all recommending
> packages are gone too, and so on.

It had some thinking, and ended up in no agreement. There's really no
reason to hack up the spec to replace one hack with another.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Michał Górny]

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

On Wed, 7 Sep 2011 11:07:21 +0200
Tomáš Chvátal <scarabeus@gentoo.org> wrote:

> Start collecting ideas for EAPI5.

I'd highlight the following bugs:

311795 - [Future EAPI] Allow dots in USE flag names
373377 - [Future EAPI] Remove IMAGE (deprecated already)

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Aaron W. Swenson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09/07/2011 11:48 AM, Michał Górny wrote:
> On Wed, 7 Sep 2011 11:07:21 +0200 Tomáš Chvátal
> <scarabeus@gentoo.org> wrote:
> 
>> Start collecting ideas for EAPI5.
> 
> I'd highlight the following bugs:
> 
> 311795 - [Future EAPI] Allow dots in USE flag names 373377 -
> [Future EAPI] Remove IMAGE (deprecated already)
> 
I second the allowing dots in USE flag names. Definitely would be
helpful for declaring version related USE flags.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk5n9HUACgkQCOhwUhu5AEk+RQEAomdG51DXzVT3CSRjGGVtoRNI
GFfmapur0VavmIj8jHIA/2sDQBbaTKKDYx4TVfQ5p2eRnw4PaSMsLnHKUgSC0HJl
=kAaj
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Ciaran McCreesh]

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

On Wed, 07 Sep 2011 18:47:17 -0400
"Aaron W. Swenson" <titanofold@gentoo.org> wrote:
> I second the allowing dots in USE flag names. Definitely would be
> helpful for declaring version related USE flags.

You know you won't be able to mention such flags in the base profile,
right? At least not for a year or more, until the base profile's eapi
can be set to something other than 0.

- -- 
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk5n9f4ACgkQ96zL6DUtXhFtdQCfY5bc8r9E0HAGYFxcI/5ozEjb
5c0AoJjY9BhzCNiWty3i1jHZm13CbNGz
=cymm
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Brian Harring]

On Wed, Sep 07, 2011 at 11:53:50PM +0100, Ciaran McCreesh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Wed, 07 Sep 2011 18:47:17 -0400
> "Aaron W. Swenson" <titanofold@gentoo.org> wrote:
> > I second the allowing dots in USE flag names. Definitely would be
> > helpful for declaring version related USE flags.
> 
> You know you won't be able to mention such flags in the base profile,
> right? At least not for a year or more, until the base profile's eapi
> can be set to something other than 0.

use.desc and use.local.desc don't have EAPI versioning either; as such 
they're eapi=0 till versioning is introduced (and then wait till the 
support is deployed far enough to avoid breaking people).

Meaning, just the same as I said on this bug... this isn't viable, and 
frankly it's not really a deal breaker lacking it.  It can be worked 
around.

If folks want it, they're going to need to sort out all of the 
backward compatibility issues *prior* to trying to shove it into eapi.

~harring

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Michał Górny]

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

On Wed, 7 Sep 2011 23:53:50 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Wed, 07 Sep 2011 18:47:17 -0400
> "Aaron W. Swenson" <titanofold@gentoo.org> wrote:
> > I second the allowing dots in USE flag names. Definitely would be
> > helpful for declaring version related USE flags.
> 
> You know you won't be able to mention such flags in the base profile,
> right? At least not for a year or more, until the base profile's eapi
> can be set to something other than 0.

Could you point me to at least a single program not supporting dots
in useflags? My quick check shows that all PMs handle them well, quse
and euse as well.

The only backwards-compat issue I see is repoman complaining. But this
can be changed easily.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Ciaran McCreesh]

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

On Thu, 15 Sep 2011 09:35:21 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> Could you point me to at least a single program not supporting dots
> in useflags? My quick check shows that all PMs handle them well, quse
> and euse as well.

Hrm, it's rather disappointing that they're accepted everywhere. That
really shouldn't happen... My excuse for Paludis is that I never quite
got around to passing in additional flags to validation of names, and
dots are legal in exheres-0, so they're currently accepted everywhere.

I'll probably get around to fixing that at some point.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Michał Górny]

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

On Thu, 15 Sep 2011 08:55:08 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Thu, 15 Sep 2011 09:35:21 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> > Could you point me to at least a single program not supporting dots
> > in useflags? My quick check shows that all PMs handle them well,
> > quse and euse as well.
> 
> Hrm, it's rather disappointing that they're accepted everywhere. That
> really shouldn't happen... My excuse for Paludis is that I never quite
> got around to passing in additional flags to validation of names, and
> dots are legal in exheres-0, so they're currently accepted everywhere.

And may I remind you that lately you deliberately changed PMS for all
EAPIs to satisfy invalid paludis behavior? And you knew that it caused
actual breakages.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Ciaran McCreesh]

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

On Thu, 15 Sep 2011 10:01:56 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> On Thu, 15 Sep 2011 08:55:08 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > On Thu, 15 Sep 2011 09:35:21 +0200
> > Michał Górny <mgorny@gentoo.org> wrote:
> > > Could you point me to at least a single program not supporting
> > > dots in useflags? My quick check shows that all PMs handle them
> > > well, quse and euse as well.
> > 
> > Hrm, it's rather disappointing that they're accepted everywhere.
> > That really shouldn't happen... My excuse for Paludis is that I
> > never quite got around to passing in additional flags to validation
> > of names, and dots are legal in exheres-0, so they're currently
> > accepted everywhere.
> 
> And may I remind you that lately you deliberately changed PMS for all
> EAPIs to satisfy invalid paludis behavior? And you knew that it caused
> actual breakages.

Huh? Not sure what you're on about here. Accepting invalid input is in
the "annoying because it leads to broken code appearing to work"
category, which is very different from "doing the wrong thing for valid
code". PMS by and large doesn't mandate validation of input (since
Portage doesn't do it at all). Think of it as being like C, where
dereferencing an invalid pointer might still work (so it's an error
for a program to do it, but not an error for a compiler to allow such
an operation to succeed), as opposed to languages like Java that require
that all memory accesses be checked.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: Text/Plain, Size: 694 bytes --]

2011-09-15 09:55:08 Ciaran McCreesh napisał(a):
> On Thu, 15 Sep 2011 09:35:21 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> > Could you point me to at least a single program not supporting dots
> > in useflags? My quick check shows that all PMs handle them well, quse
> > and euse as well.
> 
> Hrm, it's rather disappointing that they're accepted everywhere. That
> really shouldn't happen... My excuse for Paludis is that I never quite
> got around to passing in additional flags to validation of names, and
> dots are legal in exheres-0

There is no reason for Gentoo to be worse than Exherbo and not allow dots in USE flags.

-- 
Arfrever Frehtes Taifersar Arahesis

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

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Brian Harring]

On Fri, Sep 16, 2011 at 01:21:55AM +0200, Arfrever Frehtes Taifersar Arahesis wrote:
> 2011-09-15 09:55:08 Ciaran McCreesh napisał(a):
> > On Thu, 15 Sep 2011 09:35:21 +0200
> > Michał Górny <mgorny@gentoo.org> wrote:
> > > Could you point me to at least a single program not supporting dots
> > > in useflags? My quick check shows that all PMs handle them well, quse
> > > and euse as well.
> > 
> > Hrm, it's rather disappointing that they're accepted everywhere. That
> > really shouldn't happen... My excuse for Paludis is that I never quite
> > got around to passing in additional flags to validation of names, and
> > dots are legal in exheres-0
> 
> There is no reason for Gentoo to be worse than Exherbo and not allow dots in USE flags.

Seriously Arfrever, drop the rhetoric here, and go fix the profile 
compatibility issue.  Everytime you bring up dot's in use, you ignore 
compatibility, and every damn time it gets brought up I keep having 
to repeat this.  It's not productive and this has repeated for at 
least a year now.

People who want this need to sort the compat issue rather than 
sticking their heads in the sand.

~brian

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: Text/Plain, Size: 1325 bytes --]

2011-09-16 01:54:44 Brian Harring napisał(a):
> On Fri, Sep 16, 2011 at 01:21:55AM +0200, Arfrever Frehtes Taifersar Arahesis wrote:
> > 2011-09-15 09:55:08 Ciaran McCreesh napisał(a):
> > > On Thu, 15 Sep 2011 09:35:21 +0200
> > > Michał Górny <mgorny@gentoo.org> wrote:
> > > > Could you point me to at least a single program not supporting dots
> > > > in useflags? My quick check shows that all PMs handle them well, quse
> > > > and euse as well.
> > > 
> > > Hrm, it's rather disappointing that they're accepted everywhere. That
> > > really shouldn't happen... My excuse for Paludis is that I never quite
> > > got around to passing in additional flags to validation of names, and
> > > dots are legal in exheres-0
> > 
> > There is no reason for Gentoo to be worse than Exherbo and not allow dots in USE flags.
> 
> Seriously Arfrever, drop the rhetoric here, and go fix the profile 
> compatibility issue.

I suggest to support files with "-${EAPI}" suffix.
Examples:
  profiles/package.mask-5
  profiles/use.desc-5
  profiles/base/package.mask-5
  profiles/base/package.use-5
  profiles/base/package.use.force-5
  profiles/base/package.use.mask-5
  profiles/base/use.force-5
  profiles/base/use.mask-5
  profiles/desc/python_abis.desc-5

-- 
Arfrever Frehtes Taifersar Arahesis

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

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Zac Medico]

On 09/15/2011 05:20 PM, Arfrever Frehtes Taifersar Arahesis wrote:
> 2011-09-16 01:54:44 Brian Harring napisał(a):
>> On Fri, Sep 16, 2011 at 01:21:55AM +0200, Arfrever Frehtes Taifersar Arahesis wrote:
>>> 2011-09-15 09:55:08 Ciaran McCreesh napisał(a):
>>>> On Thu, 15 Sep 2011 09:35:21 +0200
>>>> Michał Górny <mgorny@gentoo.org> wrote:
>>>>> Could you point me to at least a single program not supporting dots
>>>>> in useflags? My quick check shows that all PMs handle them well, quse
>>>>> and euse as well.
>>>>
>>>> Hrm, it's rather disappointing that they're accepted everywhere. That
>>>> really shouldn't happen... My excuse for Paludis is that I never quite
>>>> got around to passing in additional flags to validation of names, and
>>>> dots are legal in exheres-0
>>>
>>> There is no reason for Gentoo to be worse than Exherbo and not allow dots in USE flags.
>>
>> Seriously Arfrever, drop the rhetoric here, and go fix the profile 
>> compatibility issue.
> 
> I suggest to support files with "-${EAPI}" suffix.
> Examples:
>   profiles/package.mask-5
>   profiles/use.desc-5
>   profiles/base/package.mask-5
>   profiles/base/package.use-5
>   profiles/base/package.use.force-5
>   profiles/base/package.use.mask-5
>   profiles/base/use.force-5
>   profiles/base/use.mask-5
>   profiles/desc/python_abis.desc-5
> 

I'd prefer not to use separate files per eapi, since that effectively
gives you multiple profiles that behave differently depending on the
supported EAPI of the package manager.

As an alternative, I suggest to use the 'eapi' file to specify the EAPI
for all files in the directory. If you want to roll out EAPI 5 profiles
sooner, then you can fork a new base profile that only supports EAPI 5
or later, and base new profiles off of that. Bumping the EAPI of the
root profiles/eapi file would be a different matter, since it applies to
the whole repository. If you want to version bump that repository-level
EAPI, then you need to wait until at least 6 months after supporting
package managers have been available in stable.
-- 
Thanks,
Zac

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Donnie Berkholz]

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

On 14:06 Fri 16 Sep     , Zac Medico wrote:
> Bumping the EAPI of the root profiles/eapi file would be a different 
> matter, since it applies to the whole repository. If you want to 
> version bump that repository-level EAPI, then you need to wait until 
> at least 6 months after supporting package managers have been 
> available in stable.

So in your opinion, it would be fine to bump profiles/eapi to EAPI=4 
now?

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com

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

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Zac Medico]

On 09/17/2011 08:47 PM, Donnie Berkholz wrote:
> On 14:06 Fri 16 Sep     , Zac Medico wrote:
>> Bumping the EAPI of the root profiles/eapi file would be a different 
>> matter, since it applies to the whole repository. If you want to 
>> version bump that repository-level EAPI, then you need to wait until 
>> at least 6 months after supporting package managers have been 
>> available in stable.
> 
> So in your opinion, it would be fine to bump profiles/eapi to EAPI=4 
> now?

Yes, it's feasible. As a consequence, we may get some complaints from
users who haven't upgraded during the last six months. For users like
these, we could take a snapshot of the tree before the EAPI is bumped,
and archive it so they can use it to update their package manager to a
version that supports the new EAPI.
-- 
Thanks,
Zac

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Brian Harring]

On Sat, Sep 17, 2011 at 10:26:57PM -0700, Zac Medico wrote:
> On 09/17/2011 08:47 PM, Donnie Berkholz wrote:
> > On 14:06 Fri 16 Sep     , Zac Medico wrote:
> >> Bumping the EAPI of the root profiles/eapi file would be a different 
> >> matter, since it applies to the whole repository. If you want to 
> >> version bump that repository-level EAPI, then you need to wait until 
> >> at least 6 months after supporting package managers have been 
> >> available in stable.
> > 
> > So in your opinion, it would be fine to bump profiles/eapi to EAPI=4 
> > now?
> 
> Yes, it's feasible. As a consequence, we may get some complaints from
> users who haven't upgraded during the last six months.


Bit more than complaints; any system running a PM older than 6 months 
or so (regardless of paludis/portage/pkgcore) will have to roll their 
own profile to merge *anything*.

Period.

A pkg going to an unsupported eapi precludes the package from being 
used; bumping the root profile node to 4 (or any node in the users 
chain) means they /cannot use that profile/.


If people are seriously going to pull something this level of 
heinous, at the very least plan it- it's a sizable enough breakage 
other things could/should be shoved in (including giving people 
significant warning).


To be absolutely clear, You bump the base to EAPI4, you're actively 
making every system w/ a 6 month lag basically invalidated.

For reference of the actual eapi usage in the tree (pinspect 
eapi_usage), is the following:

eapi: '0' 10629 pkgs found, 36.73% of the repository
eapi: '2' 7254 pkgs found, 25.07% of the repository
eapi: '3' 5315 pkgs found, 18.37% of the repository
eapi: '4' 5013 pkgs found, 17.32% of the repository
eapi: '1' 728 pkgs found, 2.52% of the repository


> For users like
> these, we could take a snapshot of the tree before the EAPI is bumped,
> and archive it so they can use it to update their package manager to a
> version that supports the new EAPI.

Target the profiles; no need to snapshot the whole tree unless the 
plan is to bump 83% of the tree forward to EAPI4 shortly there 
after (which is mildly rediculous in it's own anyways)...

~harring

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Ulrich Mueller]

>>>>> On Sat, 17 Sep 2011, Zac Medico wrote:

>> So in your opinion, it would be fine to bump profiles/eapi to
>> EAPI=4 now?

> Yes, it's feasible. As a consequence, we may get some complaints
> from users who haven't upgraded during the last six months.

<http://www.gentoo.org/proj/en/council/meeting-logs/20091109-summary.txt>
# Vote (unanimous): The ebuild tree must provide an upgrade path to a
# stable system that hasn't been updated for one year.

Ulrich

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Nirbheek Chauhan]

On Sun, Sep 18, 2011 at 10:56 AM, Zac Medico <zmedico@gentoo.org> wrote:
> On 09/17/2011 08:47 PM, Donnie Berkholz wrote:
>> On 14:06 Fri 16 Sep     , Zac Medico wrote:
>>> Bumping the EAPI of the root profiles/eapi file would be a different
>>> matter, since it applies to the whole repository. If you want to
>>> version bump that repository-level EAPI, then you need to wait until
>>> at least 6 months after supporting package managers have been
>>> available in stable.
>>
>> So in your opinion, it would be fine to bump profiles/eapi to EAPI=4
>> now?
>
> Yes, it's feasible. As a consequence, we may get some complaints from
> users who haven't upgraded during the last six months.

I don't see any features in EAPI 3 and 4 that are useful for the
profiles. However, a bump to EAPI 2 (or at least 1) would be
*extremely* beneficial, and cause much less chaos.

Speaking with my GNOME hat, it will be *extremely* useful for
slot-masking GNOME packages.

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Ciaran McCreesh]

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

On Sun, 18 Sep 2011 14:54:56 +0530
Nirbheek Chauhan <nirbheek@gentoo.org> wrote:
> I don't see any features in EAPI 3 and 4 that are useful for the
> profiles. However, a bump to EAPI 2 (or at least 1) would be
> *extremely* beneficial, and cause much less chaos.
> 
> Speaking with my GNOME hat, it will be *extremely* useful for
> slot-masking GNOME packages.

If that route is taken, I'd recommend 1 rather than 2, for the simple
reason that if 2 is introduced to profiles, we need to have a very
careful discussion about the meanings of use dependencies in profile
files.

For example, people might think they can start masking cat/pkg[flag].
Is this a replacement for package.use.mask or does it mean something
else? I have a sneaking suspicion that if there's not a policy saying
"no use deps in profiles" then people will start trying to use them for
all kinds of horrible hacks that would be better being fixed properly.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Jorge Manuel B. S. Vicetto]

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

On 18-09-2011 09:33, Ciaran McCreesh wrote:
> On Sun, 18 Sep 2011 14:54:56 +0530 Nirbheek Chauhan
> <nirbheek@gentoo.org> wrote:
>> I don't see any features in EAPI 3 and 4 that are useful for the 
>> profiles. However, a bump to EAPI 2 (or at least 1) would be 
>> *extremely* beneficial, and cause much less chaos.
>> 
>> Speaking with my GNOME hat, it will be *extremely* useful for 
>> slot-masking GNOME packages.
> 
> If that route is taken, I'd recommend 1 rather than 2, for the
> simple reason that if 2 is introduced to profiles, we need to have
> a very careful discussion about the meanings of use dependencies in
> profile files.
> 
> For example, people might think they can start masking
> cat/pkg[flag]. Is this a replacement for package.use.mask or does
> it mean something else? I have a sneaking suspicion that if there's
> not a policy saying "no use deps in profiles" then people will
> start trying to use them for all kinds of horrible hacks that would
> be better being fixed properly.

What other meanings could it have? What would be the problem with
moving the package use flag masks from package.use.mask to package.mask?

As we're talking about updating profiles EAPI, what do we need to get
to be able to mask use flags for the stable tree, but not the testing
tree? Also, should we get back to the discussion of decoupling
keywords from ebuilds and move them to profiles?

- -- 
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOdf4yAAoJEC8ZTXQF1qEPmxsQAKX/rqRhF9cnekdaVZK9oPSA
wd9GxDoof2zkUgf0UM+HH0ACzZ7cIznodK32gY+J0waBAucmq/Dn3xbrY2wrpJS7
130HqbKB+jyX+7SaT1DYdwdDJ4hAvdgAG0Vhnq6xF2lsvFPYsuq6irMzK8lXdeID
qEUMQ8+7RtrotilVyeIuiSUUp+I8Z6vdhKbqmAYf91/UP5BOFvtleF6vVimtj4HA
q+i6ELpExrIvH1zWgIJ9k0oyL+LNWCnOiajT4dy7qdy73wVy+8LLA2+nntLIbhdv
X4HSm9wHvhKsdB1OCub0rh+WFH4gBb6CoZtqSWHuzLEEXzClXsym0XxjqBu8slaj
F8+e04jTF1zO9GchDlOvAWJroOP9hsKlSJg+bbvnk4Dat72OPKA1zJf/R9XurNkn
4MWPgY7TCYbpIB2hSPHsmQ7rnxz8sj+pgDZqY8MNpqLl7XGITSMhp7Krq0yS2MOP
mkI5ZvhVkx9eqvM2MRe0KCKsC7r1U/2DSgkS+YlRmUvD2ts08miY5Ce2bVS4OWP3
5Wr5mVBJTlMMrN0NUX0LVtt3yuDV6voVeyxEI3iCMRAfYde34ddpFJ3e5x8q7bAA
aldoJ8383J6RWhx7dBhnLgQ/zQm94E4g9o9sJW5sYwcfZ4qOh+SQbnuI7HVxEj2e
vuvrabJqE2RsjHfJcW+y
=axJ6
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Ciaran McCreesh]

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

On Sun, 18 Sep 2011 14:20:34 +0000
"Jorge Manuel B. S. Vicetto" <jmbsvicetto@gentoo.org> wrote:
> > For example, people might think they can start masking
> > cat/pkg[flag]. Is this a replacement for package.use.mask or does
> > it mean something else? I have a sneaking suspicion that if there's
> > not a policy saying "no use deps in profiles" then people will
> > start trying to use them for all kinds of horrible hacks that would
> > be better being fixed properly.
> 
> What other meanings could it have? What would be the problem with
> moving the package use flag masks from package.use.mask to
> package.mask?

Well, the behaviour is likely going to be different. Unless a package
manager adds in special behaviour to cover this, use dependencies in
package.mask will prevent an upgrade whereas package.use.mask allows
the upgrade but disables the flag.

I think that example illustrates perfectly why we don't want to just
blindly enable EAPI 2 in profiles.

> As we're talking about updating profiles EAPI, what do we need to get
> to be able to mask use flags for the stable tree, but not the testing
> tree?

Every time this has come up, the conclusion has been "it's a horrible
idea from a QA perspective, since it would mean that testing something
in ~arch would be different to testing it in arch".

> Also, should we get back to the discussion of decoupling
> keywords from ebuilds and move them to profiles?

So far as I'm aware, "not using CVS" is a prerequisite for this.

- -- 
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEARECAAYFAk52FT0ACgkQ96zL6DUtXhHrKACfRYXquFwMl3quPb7vmUwoSsO5
FFsAnjrYE9kJRMBoInAY1cWe6XiyAJ4m
=TQGA
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Rich Freeman]

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

On Sep 18, 2011 12:05 PM, "Ciaran McCreesh" <ciaran.mccreesh@googlemail.com>
wrote:
> On Sun, 18 Sep 2011 14:20:34 +0000
> "Jorge Manuel B. S. Vicetto" <jmbsvicetto@gentoo.org> wrote:
> > As we're talking about updating profiles EAPI, what do we need to get
> > to be able to mask use flags for the stable tree, but not the testing
> > tree?
>
> Every time this has come up, the conclusion has been "it's a horrible
> idea from a QA perspective, since it would mean that testing something
> in ~arch would be different to testing it in arch".
>

Isn't that already true from a dependency standpoint?  I do see your point,
but the concept of rolling out a risky flag to the brave first does make
sense.

I think the biggest issue with ~arch is when things get deployed there for a
very long time before hitting stable. That applies to libraries,
baselayout-2, or flags. Things shouldn't go to ~arch unless we have a plan
to make them stable (excepting one-offs).

Rich

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

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Nirbheek Chauhan]

On Sun, Sep 18, 2011 at 7:50 PM, Jorge Manuel B. S. Vicetto
<jmbsvicetto@gentoo.org> wrote:
> As we're talking about updating profiles EAPI, what do we need to get
> to be able to mask use flags for the stable tree, but not the testing
> tree?

What's wrong with versioned masking of use-flags? The fact that they
have to be constantly maintained is actually a good thing since it
means that people will keep revisiting the mask with every STABLEREQ,
and it won't get outdated and forgotten.

> Also, should we get back to the discussion of decoupling
> keywords from ebuilds and move them to profiles?
>

What's the use-case for this? What is the new proposed format to store
the keywords?

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Zac Medico]

On 09/18/2011 07:20 AM, Jorge Manuel B. S. Vicetto wrote:
> What other meanings could it have? What would be the problem with
> moving the package use flag masks from package.use.mask to package.mask?

As Ciaran said, these two kinds of masks give two very different
behaviors that are not interchangeable in current dependency resolvers.
If you make make them interchangeable, then you take away a kind of
granularity that is provided by having them separate, and you also have
to change how the dependency resolvers handle them in all package
managers (and repoman too).

> As we're talking about updating profiles EAPI, what do we need to get
> to be able to mask use flags for the stable tree, but not the testing
> tree? Also, should we get back to the discussion of decoupling
> keywords from ebuilds and move them to profiles?

As I have said before [1], I would suggest to create separate profiles
for stable and unstable, and add separate entries to profiles.desc so
that repoman can check them separately.

[1]
http://archives.gentoo.org/gentoo-dev/msg_32b26e8f276201923a8fb05dc83d8832.xml
-- 
Thanks,
Zac

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Michał Górny]

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

On Sun, 18 Sep 2011 10:33:32 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Sun, 18 Sep 2011 14:54:56 +0530
> Nirbheek Chauhan <nirbheek@gentoo.org> wrote:
> > I don't see any features in EAPI 3 and 4 that are useful for the
> > profiles. However, a bump to EAPI 2 (or at least 1) would be
> > *extremely* beneficial, and cause much less chaos.
> > 
> > Speaking with my GNOME hat, it will be *extremely* useful for
> > slot-masking GNOME packages.
> 
> If that route is taken, I'd recommend 1 rather than 2, for the simple
> reason that if 2 is introduced to profiles, we need to have a very
> careful discussion about the meanings of use dependencies in profile
> files.
> 
> For example, people might think they can start masking cat/pkg[flag].
> Is this a replacement for package.use.mask or does it mean something
> else? I have a sneaking suspicion that if there's not a policy saying
> "no use deps in profiles" then people will start trying to use them
> for all kinds of horrible hacks that would be better being fixed
> properly.

Do you consider masking USE flags in repositories a 'horrible hack'?
Because that's the use I see for newer-EAPI profile.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Ciaran McCreesh]

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

On Sun, 18 Sep 2011 16:47:14 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> > For example, people might think they can start masking
> > cat/pkg[flag]. Is this a replacement for package.use.mask or does
> > it mean something else? I have a sneaking suspicion that if there's
> > not a policy saying "no use deps in profiles" then people will
> > start trying to use them for all kinds of horrible hacks that would
> > be better being fixed properly.
> 
> Do you consider masking USE flags in repositories a 'horrible hack'?
> Because that's the use I see for newer-EAPI profile.

I'm not entirely sure what you mean by that.

Which is pretty much the problem: it's really not clear what use
dependencies in profile files mean.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Brian Harring]

On Thu, Sep 15, 2011 at 09:35:21AM +0200, Micha?? G??rny wrote:
> On Wed, 7 Sep 2011 23:53:50 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> 
> > On Wed, 07 Sep 2011 18:47:17 -0400
> > "Aaron W. Swenson" <titanofold@gentoo.org> wrote:
> > > I second the allowing dots in USE flag names. Definitely would be
> > > helpful for declaring version related USE flags.
> > 
> > You know you won't be able to mention such flags in the base profile,
> > right? At least not for a year or more, until the base profile's eapi
> > can be set to something other than 0.
> 
> Could you point me to at least a single program not supporting dots
> in useflags? My quick check shows that all PMs handle them well, quse
> and euse as well.

pmerge -pv sys-apps/portage[it.validate.atom.use.flags.just.not.make.conf]

~harring

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Ciaran McCreesh]

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

On Wed, 7 Sep 2011 11:07:21 +0200
Tomáš Chvátal <scarabeus@gentoo.org> wrote:
> Start collecting ideas for EAPI5.

http://archives.gentoo.org/gentoo-pms/msg_dfef93f8d6bc6684d4dc9793563b4fdf.xml

was my list. There are also various bits of lousy wording in PMS that
I'd like to get cleared up over an EAPI (such as what exactly a self
block does).

The problem is, we can't get a reliable answer to "can this be
implemented in Portage quickly?"...

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Thomas Sachau]

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

Tomáš Chvátal schrieb:
> Start collecting ideas for EAPI5.

1) USE-flag based support to cross-compile packages (mostly implemented in multilib-portage)
2) USE-flag based support to install for different slots (e.g. python, ruby or php)
3) (internal) USE-flag based support to re-install packages (replacement for
revdep-rebuild/@preserved-rebuild)

The order of the list is also in the order of how much of it is already implemented and could be
easily drafted.

The first one already has a working implementation, so might just need some smaller adjustments.

The second one is already done in some eclasses, afaik php and ruby, but it might be a good idea to
have a general framework for all slotted languages, so there is no need to re-implement the same for
every language.

The third one is mostly an idea, where packages requiring a rebuild of depending packages define a
specific var (SLOT or some new one line ABI_SLOT, which needs to be updated, when depending packages
need to be rebuild), so that whenever this var is updated, all depending packages have to be
rebuild. This probably needs a bit more of discussion and thinking to get it properly drafted.


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

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Alec Warner]

On Thu, Sep 8, 2011 at 10:03 AM, Thomas Sachau <tommy@gentoo.org> wrote:
> Tomáš Chvátal schrieb:
>> Start collecting ideas for EAPI5.
>
> 1) USE-flag based support to cross-compile packages (mostly implemented in multilib-portage)
> 2) USE-flag based support to install for different slots (e.g. python, ruby or php)
> 3) (internal) USE-flag based support to re-install packages (replacement for
> revdep-rebuild/@preserved-rebuild)
>
> The order of the list is also in the order of how much of it is already implemented and could be
> easily drafted.
>
> The first one already has a working implementation, so might just need some smaller adjustments.
>
> The second one is already done in some eclasses, afaik php and ruby, but it might be a good idea to
> have a general framework for all slotted languages, so there is no need to re-implement the same for
> every language.
>
> The third one is mostly an idea, where packages requiring a rebuild of depending packages define a
> specific var (SLOT or some new one line ABI_SLOT, which needs to be updated, when depending packages
> need to be rebuild), so that whenever this var is updated, all depending packages have to be
> rebuild. This probably needs a bit more of discussion and thinking to get it properly drafted.

I thought the usual problem behind this wasn't so much the
implementation but instead was getting maintainers to change the
ABI_SLOT on a library would be difficult. Either they would do it too
often (unnecessarily) or they would not do it enough (so we would
still need revdep & friends.)

>
>

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Ole Markus With]

On Thu, 08 Sep 2011 19:03:56 +0200, Thomas Sachau <tommy@gentoo.org> wrote:

> Tomáš Chvátal schrieb:
>> Start collecting ideas for EAPI5.
>
> 2) USE-flag based support to install for different slots (e.g. python,  
> ruby or php)
>
> The second one is already done in some eclasses, afaik php and ruby, but  
> it might be a good idea to
> have a general framework for all slotted languages, so there is no need  
> to re-implement the same for
> every language.
>

I would definately like to see something around this. It feels silly that  
slotted languages and its package behave almost the same, but different  
enough for it to be quite annoying for the end users.

Also those packagers who have to deal with language bindings towards  
multiple slotted languages experience quite a lot of pain because of how  
differently this behaviour is implemented in the various eclasses.


-- 
Ole Markus

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: Text/Plain, Size: 845 bytes --]

2011-09-08 19:03:56 Thomas Sachau napisał(a):
> Tomáš Chvátal schrieb:
> > Start collecting ideas for EAPI5.
> 
> 2) USE-flag based support to install for different slots (e.g. python, ruby or php)
> 
> The second one is already done in some eclasses, afaik php and ruby, but it might be a good idea to
> have a general framework for all slotted languages, so there is no need to re-implement the same for
> every language.

It's better to have it implemented in eclasses. E.g. Python scripts need to be specially handled
(python_merge_intermediate_installation_images() renames them (so that their names include
Python ABI), calls python_convert_shebangs() if they don't have appropriate shebangs, and calls
python_generate_wrapper_scripts() to create appropriate wrapper scripts).

-- 
Arfrever Frehtes Taifersar Arahesis

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

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Michał Górny]

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

On Thu, 8 Sep 2011 20:10:23 +0200
Arfrever Frehtes Taifersar Arahesis <arfrever.fta@gmail.com> wrote:

> 2011-09-08 19:03:56 Thomas Sachau napisał(a):
> > Tomáš Chvátal schrieb:
> > > Start collecting ideas for EAPI5.
> > 
> > 2) USE-flag based support to install for different slots (e.g.
> > python, ruby or php)
> > 
> > The second one is already done in some eclasses, afaik php and
> > ruby, but it might be a good idea to have a general framework for
> > all slotted languages, so there is no need to re-implement the same
> > for every language.
> 
> It's better to have it implemented in eclasses. E.g. Python scripts
> need to be specially handled
> (python_merge_intermediate_installation_images() renames them (so
> that their names include Python ABI), calls python_convert_shebangs()
> if they don't have appropriate shebangs, and calls
> python_generate_wrapper_scripts() to create appropriate wrapper
> scripts).

Eclasses itself can't handle this in really useful manner. PM needs to
provide us with a nice ability to handle all that. Otherwise, we end up
with more and more ugly hacks and needless rebuilds.

The point in ABI slots should be to let PM build each slot
independently and handle cross-slot depends. IOW, if I build one
package for multiple python ABIs, I don't need every other python
package built for all of them.

Same goes for multilib -- I need 32-bit libs for wine, not for
the whole system. And I want them being built when I start needing
them, without requiring a rebuild of half of the system. And with
separate USEflags.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Ciaran McCreesh]

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

On Thu, 8 Sep 2011 20:35:48 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> PM needs to provide us with a nice ability to handle all that.

I've yet to see a complete, detailed, accurate description of what "all
that" really is. It's a bit hard to come up with an EAPI solution when
we don't know what the problem is.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Michał Górny]

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

On Thu, 8 Sep 2011 19:33:03 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Thu, 8 Sep 2011 20:35:48 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> > PM needs to provide us with a nice ability to handle all that.
> 
> I've yet to see a complete, detailed, accurate description of what
> "all that" really is. It's a bit hard to come up with an EAPI
> solution when we don't know what the problem is.

I wasn't the person suggesting this for EAPI5. I was rather pointing
out we're not ready for that.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1081 bytes --]

On Thursday, September 08, 2011 14:10:23 Arfrever Frehtes Taifersar Arahesis 
wrote:
> 2011-09-08 19:03:56 Thomas Sachau napisał(a):
> > Tomáš Chvátal schrieb:
> > > Start collecting ideas for EAPI5.
> > 
> > 2) USE-flag based support to install for different slots (e.g. python,
> > ruby or php)
> > 
> > The second one is already done in some eclasses, afaik php and ruby, but
> > it might be a good idea to have a general framework for all slotted
> > languages, so there is no need to re-implement the same for every
> > language.
> 
> It's better to have it implemented in eclasses. E.g. Python scripts need to
> be specially handled (python_merge_intermediate_installation_images()
> renames them (so that their names include Python ABI), calls
> python_convert_shebangs() if they don't have appropriate shebangs, and
> calls python_generate_wrapper_scripts() to create appropriate wrapper
> scripts).

the EAPI still needs updating so that SLOT can contain USE flag based values.  
like USE=multislot that binutils/gcc has carried forever.
-mike

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

proposal for cross-compie support in EAPI-5, was: Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Thomas Sachau]

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

Thomas Sachau schrieb:
> Tomáš Chvátal schrieb:
>> Start collecting ideas for EAPI5.
> 
> 1) USE-flag based support to cross-compile packages (mostly implemented in multilib-portage)

let me extend this a bit, first the reasoning behind it:


For amd64 users, there is sometimes the issue, that they need 32bit libs for certain packages (e.g.
wine or many binary-only packages). Currently, they only get them prepackaged in binary form with
the emul-linux-x86-* packages. But those packages have a few issues (list does not have to be complete):

-they only contain a limited set of 32bit packages
-they are precompiled, so the user cannot define his own flags
-they have to be manually maintained and updated


So the idea was to add the ability to compile 32bit packages with support from the package manager,
so there is no need for additional packages to maintain. After this was originally implemented, it
was further extended to allow cross-compilation for other targets, not only limited to 32bit packages.


The basic way, how this should work:

First, there is the check, if the current setup is prepared for cross-compilation, for this, the
content of the MULTILIB_ABIS var is checked. If it has more than 1 (space seperated) value, those
values are taken and converted into USE flags in the format of multilib_abi_$ABI.
In the case of current amd64 multilib profile, which i will take as base for my examples, this means
2 additional USE flags: multilib_abi_amd64 and multilib_abi_x86.
Those USE flags are internally USE_EXPANDed, so the output after the normal USE flags is in the form
of this: MULTILIB_ABI="amd64 -x86"
This way, the user is able to define the target ABIs for each package independently from global
settings.
During dependency calculation, every dependency gets additional USE deps for every target ABI, in
this example: category/package[multilib_abi_amd64?,multilib_abi_x86?].
This ensures, that the required dependencies also have the needed 32bit libs/binaries for the
requested package.
Before the pkg_setup phase is executed, the environment is setup for the first target ABI (in this
example: amd64), to make it short, i will just copy the current code from multilib-portage for this:

>         # Set the CHOST native first so that we pick up the native
>         # toolchain and not a cross-compiler by accident #202811.
>         export CHOST=$(get_abi_var CHOST ${DEFAULT_ABI})
>         export AS="$(tc-getPROG AS as)"
>         export CC="$(tc-getPROG CC gcc)"
>         export CXX="$(tc-getPROG CXX g++)"
>         export FC="$(tc-getPROG FC gfortran)"
>         export CHOST=$(get_abi_var CHOST $1)
>         export CBUILD=$(get_abi_var CHOST $1)
>         export CDEFINE="$(get_abi_var CDEFINE $1)"
>         export CCASFLAGS="${CCASFLAGS:-${CFLAGS}} $(get_abi_var CFLAGS)"
>         export CFLAGS="${CFLAGS} $(get_abi_var CFLAGS)"
>         export CPPFLAGS="${CPPFLAGS} $(get_abi_var CPPFLAGS)"
>         export CXXFLAGS="${CXXFLAGS} $(get_abi_var CFLAGS)"
>         export FCFLAGS="${FCFLAGS} $(get_abi_var CFLAGS)"
>         export FFLAGS="${FFLAGS} $(get_abi_var CFLAGS)"
>         export ASFLAGS="${ASFLAGS} $(get_abi_var ASFLAGS)"
>         export LDFLAGS="${LDFLAGS} $(get_abi_var CFLAGS)"
>         local LIBDIR=$(get_abi_var LIBDIR $1)
>         export PKG_CONFIG_PATH="/usr/${LIBDIR}/pkgconfig"
>         if [[ "${ABI}" != "${DEFAULT_ABI}" ]]; then
>                 [[ -z ${CCACHE_DIR} ]] || export CCACHE_DIR=${CCACHE_DIR}/${ABI}
>         fi

After this, all phases until after src_install are executed as usual.

After src_install, there are some checks:
If there is another target ABI, the install dir is checked for possible abi-specific files (headers,
libs, binaries).
If both conditions are true, the current install dir is saved in a different location, everything
cleaned up and the package manager starts again at the preparation step for the target ABI before
pkg_setup. This is done until all target ABIs have been done.

Now comes the merging step: For each target ABI, the installed files get moved back to the original
install location with 2 exceptions:
-if the headers differ between the target ABIs, they get installed into abi-specific subdirectories
and the original header file becomes a wrapper file, which includes the abi-specific header file
depending on the current environenment.
-if there are binaries (and this step is not restricted), those get moved into their original
location, but with an abi-specific appendix, the original file is replaced by a symlink to an
abi-wrapper, which executes the abi-specific binary depending on the current environment.

After this is done, following phases are executed. the pkg_* phases after src_install are looped
over all currently enabled target ABIs. This ensures, that abi-specific commands are executed for
every target ABI.

Differences, options and other things with current multilib-portage implementation:

The binary wrapping in current multilib-portage is only happening, if the package is defined in the
MULTILIB_BINARIES var to avoid the modification of existing ebuilds. For my proposal, this wrapping
should happen by default, unless this is restricted in the ebuild, e.g. by RESTRICT="multilib-binaries".

Another usefull thing not currently enabled in multilib-portage: Instead of having the USE flag for
the current platform internally enabled (in this example, USE=amd64), the target ABI should be the
currently active internal USE flag (in this example, USE=x86 during compilation for x86). This
allows for abi-specific changes and would also allow to install abi-specific files for binary
packages (if there is a binary package for the target ABI and a loop over all enabled target ABIs in
pkg_fetch done).

Since none of this directly affects the ebuilds, the package manager can optionally enable this for
all packages (like multilib-portage does currently), the main point, why this needs to go into an
EAPI is the ability to require a package to provide files for a different target ABI (e.g. packages
for amd64 could directly depend on category/package[multilib_abi_x86], if they require the 32bit
libs of this package).


I hope, this can be at least the base (together with the existing implementation in
multilib-portage) for a spec to get cross-compile support into EAPI-5.

For reference:
-the code of current multilib-portage is in the portage repository on git.overlays.gentoo.org inside
the multilib branch
-an ebuild to install multilib-portage is in the multilib overlay in the portage-multilib branch
(current version in there is 2.2.0_alpha55-r1, i need to merge the most recent changes of portage,
so it might sometimes be a bit behind the latest portage version)
-a minimal stage4 with multilib-portage (also already some months old) can be found in a qemu image
on our distfiles mirrors inside experimental/amd64/qemu/, it is called
multilib-amd64-qemu-2010-12-08.img.lzma


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