* Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC
2012-08-12 21:05 ` Ulrich Mueller
@ 2012-08-12 21:13 ` Michał Górny
2012-08-13 7:41 ` hasufell
` (4 subsequent siblings)
5 siblings, 0 replies; 25+ messages in thread
From: Michał Górny @ 2012-08-12 21:13 UTC (permalink / raw
To: gentoo-project; +Cc: ulm
[-- Attachment #1: Type: text/plain, Size: 842 bytes --]
On Sun, 12 Aug 2012 23:05:04 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:
> * User patches
> - Current wording of the spec requires that every ebuild includes a
> call to the apply_user_patches_here function in src_prepare.
> A alternative would be to apply user patches after src_prepare as
> a default, if the ebuild doesn't call the respective function.
> - Are we happy with the name apply_user_patches_here?
> (epatch_user? euserpatch?)
> http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=a8bf7862967cce36b7f1b408934a774126da2538<
I would like to add one more point here:
- The spec doesn't provide any kind of epatch function, so we will end
up having two copies of epatch, one for user patches, and the other
(from eclass) for ebuilds.
--
Best regards,
Michał Górny
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC
2012-08-12 21:05 ` Ulrich Mueller
2012-08-12 21:13 ` Michał Górny
@ 2012-08-13 7:41 ` hasufell
2012-08-14 7:02 ` Arfrever Frehtes Taifersar Arahesis
` (3 subsequent siblings)
5 siblings, 0 replies; 25+ messages in thread
From: hasufell @ 2012-08-13 7:41 UTC (permalink / raw
To: gentoo-project
On 08/12/2012 11:05 PM, Ulrich Mueller wrote:
>>>>>> On Tue, 7 Aug 2012, Fabian Groffen wrote:
>
> Third, things where I think that some additional discussion is needed:
>
> * econf --disable-silent-rules
> - Doesn't seem controversial for EAPI 5.
> - It has been suggested that this is applied retroactively to EAPI 4.
> http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=b7750e67b4772c1064543defb7df6a556f09807b
> https://bugs.gentoo.org/show_bug.cgi?id=379497
>
Please note that this is only one of 3 suggestions:
1. apply it for EAPI=5
2. apply it for EAPI>=4
3. apply it for all EAPIs
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC
2012-08-12 21:05 ` Ulrich Mueller
2012-08-12 21:13 ` Michał Górny
2012-08-13 7:41 ` hasufell
@ 2012-08-14 7:02 ` Arfrever Frehtes Taifersar Arahesis
2012-08-14 9:24 ` Ciaran McCreesh
2012-08-14 8:15 ` Michał Górny
` (2 subsequent siblings)
5 siblings, 1 reply; 25+ messages in thread
From: Arfrever Frehtes Taifersar Arahesis @ 2012-08-14 7:02 UTC (permalink / raw
To: gentoo-project
[-- Attachment #1: Type: Text/Plain, Size: 3661 bytes --]
2012-08-12 23:05:04 Ulrich Mueller napisał(a):
> >>>>> On Tue, 7 Aug 2012, Fabian Groffen wrote:
>
> > 2. EAPI5 features (10 minutes)
> > (no link, archives is not up-to-date, gmane misses the mail, marc
> > doesn't have gentoo-project, mail by ulm in reply to dilfridge on 21st
> > of July)
> > * vote on the tentative list of EAPI 5 features
> > (ulm: please provide said list)
>
> Sorry for the delay. The list of candidates for EAPI 5 is included
> below. I've grouped them into four categories:
>
>
> First, features where a preliminary wording of the spec is already
> available, and that don't seem to be controversial:
>
> * Slot operator dependencies
> http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=f9f7729c047300e1924ad768a49c660e12c2f906
> https://bugs.gentoo.org/show_bug.cgi?id=229521
>
> * Profile IUSE injection
> http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=d9040ab3482af5f790368bac5d053bf1cd760ba8
> https://bugs.gentoo.org/show_bug.cgi?id=176467
>
> * Remove IMAGE variable
> http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=489a60deede1a0d78edb545e97b0e17addaa6ab4
> https://bugs.gentoo.org/show_bug.cgi?id=373377
>
> * At-most-one-of operator for REQUIRED_USE
> http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=1c2dff2df2305aff88a734e3a2716de1bb69f3b6
> https://bugs.gentoo.org/show_bug.cgi?id=354219
>
> * EBUILD_PHASE_FUNC variable
> http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=76ddca560da42fd968c53a2a0c38a6ac840a7ad4
> https://bugs.gentoo.org/show_bug.cgi?id=390765
>
> * Mandate GNU find
> http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=472690942e14f63f1b1f3a5681976a59539ea3f8
> https://bugs.gentoo.org/show_bug.cgi?id=384157
>
> * new* commands can read from standard input
> http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=4939df8586c7b17b03d8627a8371c988f4445a26
> https://bugs.gentoo.org/show_bug.cgi?id=263565
>
> * Parsing of the EAPI assignment is mandatory
> http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=91d1e1e39b034bde7e5b981a5616a127135f37fa
>
> * src_test support for parallel tests
> http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=3ec4b3c22582a8ec206bce1e93bab377d7b264b5
> https://bugs.gentoo.org/show_bug.cgi?id=363005
>
> * Stable use forcing and masking
> http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=2921080e5b4f67ae55d2f80f8fea2b8d47ced831
>
>
> Second, features where a spec hasn't been written yet, but which look
> easy:
>
> * doheader helper function
> https://bugs.gentoo.org/show_bug.cgi?id=21310
>
> * usex helper function
> https://bugs.gentoo.org/show_bug.cgi?id=382963
>
> * has_version and best_version argument for ROOT
> https://bugs.gentoo.org/show_bug.cgi?id=401239
You forgot about the following features (already implemented in Portage):
* package.mask, use.force, use.mask, package.use, package.use.force and package.use.mask directories
https://bugs.gentoo.org/show_bug.cgi?id=282296
* REPOSITORY variable
https://bugs.gentoo.org/show_bug.cgi?id=414813
* Repository dependencies
https://bugs.gentoo.org/show_bug.cgi?id=414815
* make.defaults, use.force, use.mask, package.use, package.use.force and package.use.mask in ${repository_path}/profiles
https://bugs.gentoo.org/show_bug.cgi?id=414817
* Extended default list of extensions in dohtml
https://bugs.gentoo.org/show_bug.cgi?id=423245
--
Arfrever Frehtes Taifersar Arahesis
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC
2012-08-14 7:02 ` Arfrever Frehtes Taifersar Arahesis
@ 2012-08-14 9:24 ` Ciaran McCreesh
0 siblings, 0 replies; 25+ messages in thread
From: Ciaran McCreesh @ 2012-08-14 9:24 UTC (permalink / raw
To: gentoo-project
[-- Attachment #1: Type: text/plain, Size: 925 bytes --]
On Tue, 14 Aug 2012 09:02:02 +0200
Arfrever Frehtes Taifersar Arahesis <arfrever.fta@gmail.com> wrote:
> * package.mask, use.force, use.mask, package.use, package.use.force
> and package.use.mask directories
> https://bugs.gentoo.org/show_bug.cgi?id=282296
> * make.defaults, use.force, use.mask, package.use, package.use.force
> and package.use.mask in ${repository_path}/profiles
> https://bugs.gentoo.org/show_bug.cgi?id=414817
These two need a profiles EAPI bump, and we've not discussed what
happens when profiles go over EAPI 1 yet.
> * REPOSITORY variable
> https://bugs.gentoo.org/show_bug.cgi?id=414813
>
> * Repository dependencies
> https://bugs.gentoo.org/show_bug.cgi?id=414815
These two are widely considered undesirable. The second one also has a
rather large "we don't agree on what it means, but whatever it means
it isn't want you naively want" issue.
--
Ciaran McCreesh
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC
2012-08-12 21:05 ` Ulrich Mueller
` (2 preceding siblings ...)
2012-08-14 7:02 ` Arfrever Frehtes Taifersar Arahesis
@ 2012-08-14 8:15 ` Michał Górny
2012-08-14 9:02 ` Zac Medico
2012-08-14 14:01 ` Ulrich Mueller
5 siblings, 0 replies; 25+ messages in thread
From: Michał Górny @ 2012-08-14 8:15 UTC (permalink / raw
To: gentoo-project; +Cc: ulm
[-- Attachment #1: Type: text/plain, Size: 774 bytes --]
On Sun, 12 Aug 2012 23:05:04 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:
> >>>>> On Tue, 7 Aug 2012, Fabian Groffen wrote:
>
> > 2. EAPI5 features (10 minutes)
> > (no link, archives is not up-to-date, gmane misses the mail, marc
> > doesn't have gentoo-project, mail by ulm in reply to dilfridge
> > on 21st of July)
> > * vote on the tentative list of EAPI 5 features
> > (ulm: please provide said list)
>
> Sorry for the delay. The list of candidates for EAPI 5 is included
> below. I've grouped them into four categories:
>
> [...]
>
> Second, features where a spec hasn't been written yet, but which look
> easy:
* Source eclasses only once
https://bugs.gentoo.org/show_bug.cgi?id=422533
--
Best regards,
Michał Górny
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC
2012-08-12 21:05 ` Ulrich Mueller
` (3 preceding siblings ...)
2012-08-14 8:15 ` Michał Górny
@ 2012-08-14 9:02 ` Zac Medico
2012-08-14 14:01 ` Ulrich Mueller
5 siblings, 0 replies; 25+ messages in thread
From: Zac Medico @ 2012-08-14 9:02 UTC (permalink / raw
To: gentoo-project; +Cc: ulm
On 08/12/2012 02:05 PM, Ulrich Mueller wrote:
> First, features where a preliminary wording of the spec is already
> available, and that don't seem to be controversial:
>
> * Slot operator dependencies
> http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=f9f7729c047300e1924ad768a49c660e12c2f906
> https://bugs.gentoo.org/show_bug.cgi?id=229521
We could easily extend SLOT operator dependencies to support sub-slots,
as implemented in EAPI 4-slot-abi:
http://blogs.gentoo.org/zmedico/2012/06/23/automatic-rebuilds-with-experimental-eapi-4-slot-abi/
http://dev.gentoo.org/~zmedico/portage/doc/portage.html#package-ebuild-eapi-4-slot-abi
It's been tested in the axs overlay:
http://git.overlays.gentoo.org/gitweb/?p=dev/axs.git
https://bugs.gentoo.org/show_bug.cgi?id=424429
--
Thanks,
Zac
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC
2012-08-12 21:05 ` Ulrich Mueller
` (4 preceding siblings ...)
2012-08-14 9:02 ` Zac Medico
@ 2012-08-14 14:01 ` Ulrich Mueller
2012-08-14 16:09 ` Richard Yao
2012-08-14 21:17 ` Andreas K. Huettel
5 siblings, 2 replies; 25+ messages in thread
From: Ulrich Mueller @ 2012-08-14 14:01 UTC (permalink / raw
To: gentoo-project; +Cc: council
>>>>> On Sun, 12 Aug 2012, Ulrich Mueller wrote:
> The list of candidates for EAPI 5 is included below.
Here is an updated list, based on the replies to my original message.
First, features where a preliminary wording of the spec is already
available, and that don't seem to be controversial:
* Slot operator dependencies
http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=f9f7729c047300e1924ad768a49c660e12c2f906
https://bugs.gentoo.org/show_bug.cgi?id=229521
* Profile IUSE injection
http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=d9040ab3482af5f790368bac5d053bf1cd760ba8
https://bugs.gentoo.org/show_bug.cgi?id=176467
* Remove IMAGE variable
http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=489a60deede1a0d78edb545e97b0e17addaa6ab4
https://bugs.gentoo.org/show_bug.cgi?id=373377
* At-most-one-of operator for REQUIRED_USE
http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=1c2dff2df2305aff88a734e3a2716de1bb69f3b6
https://bugs.gentoo.org/show_bug.cgi?id=354219
* EBUILD_PHASE_FUNC variable
http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=76ddca560da42fd968c53a2a0c38a6ac840a7ad4
https://bugs.gentoo.org/show_bug.cgi?id=390765
* Mandate GNU find
http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=472690942e14f63f1b1f3a5681976a59539ea3f8
https://bugs.gentoo.org/show_bug.cgi?id=384157
* new* commands can read from standard input
http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=4939df8586c7b17b03d8627a8371c988f4445a26
https://bugs.gentoo.org/show_bug.cgi?id=263565
* Parsing of the EAPI assignment is mandatory
http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=91d1e1e39b034bde7e5b981a5616a127135f37fa
* src_test support for parallel tests
http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=3ec4b3c22582a8ec206bce1e93bab377d7b264b5
https://bugs.gentoo.org/show_bug.cgi?id=363005
* Stable use forcing and masking
http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=2921080e5b4f67ae55d2f80f8fea2b8d47ced831
Second, features where a spec hasn't been written yet, but which look
easy:
* doheader helper function
https://bugs.gentoo.org/show_bug.cgi?id=21310
* usex helper function
https://bugs.gentoo.org/show_bug.cgi?id=382963
* has_version and best_version argument for ROOT
https://bugs.gentoo.org/show_bug.cgi?id=401239
Third, things where I think that some additional discussion is needed:
* econf --disable-silent-rules
- Doesn't seem controversial for EAPI 5.
- It has been suggested that this is applied retroactively, either
for EAPI 4 only, or for all EAPIs.
http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=b7750e67b4772c1064543defb7df6a556f09807b
https://bugs.gentoo.org/show_bug.cgi?id=379497
* Extend SLOT operator dependencies to support sub-slots
- As suggested by zmedico.
http://blogs.gentoo.org/zmedico/2012/06/23/automatic-rebuilds-with-experimental-eapi-4-slot-abi/
http://dev.gentoo.org/~zmedico/portage/doc/portage.html#package-ebuild-eapi-4-slot-abi
https://bugs.gentoo.org/show_bug.cgi?id=424429
* User patches
- Current wording of the spec requires that every ebuild includes a
call to the apply_user_patches function in src_prepare.
A alternative would be to apply user patches after src_prepare as
a default, if the ebuild doesn't call the respective function.
- The spec doesn't provide any kind of epatch function, so we will
end up having two copies of epatch, one for user patches, and the
other (from eclass) for ebuilds.
- Are we happy with the name apply_user_patches?
(epatch_user? euserpatch?)
http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=a8bf7862967cce36b7f1b408934a774126da2538<
* License groups in ebuilds
- A simpler solution would be create separate license files like
GPL-2+ for the few cases where this is needed. This would have the
advantage that it could be applied to all EAPIs.
https://bugs.gentoo.org/show_bug.cgi?id=287192
* EJOBS variable
- Discussion was almost 4 years ago. Is there (still) consensus?
http://archives.gentoo.org/gentoo-dev/msg_750e33f68b16d971dff1f40dd9145e56.xml
* Source eclasses only once
https://bugs.gentoo.org/show_bug.cgi?id=422533
http://marc.info/?l=gentoo-dev&m=134493783816587&w=2
* Extended default list of extensions in dohtml
- Objections against inclusion of non-standard extensions like .ico
have been raised.
https://bugs.gentoo.org/show_bug.cgi?id=423245
* REPOSITORY variable
- Controversial, see bug.
https://bugs.gentoo.org/show_bug.cgi?id=414813
* Repository dependencies
- Controversial, see bug.
https://bugs.gentoo.org/show_bug.cgi?id=414815
Finally, not sure if the following are candidates for EAPI 5:
* Cross-compile support
http://archives.gentoo.org/gentoo-project/msg_b1e2b88bbeb667a3fa834c99a1981fbe.xml
* package.mask, use.force, use.mask, package.use, package.use.force
and package.use.mask directories
- Need profiles EAPI bump
https://bugs.gentoo.org/show_bug.cgi?id=282296
* make.defaults, use.force, use.mask, package.use, package.use.force
and package.use.mask in ${repository_path}/profiles
- Need profiles EAPI bump
https://bugs.gentoo.org/show_bug.cgi?id=414817
Ulrich
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC
2012-08-14 14:01 ` Ulrich Mueller
@ 2012-08-14 16:09 ` Richard Yao
2012-08-14 16:42 ` Richard Yao
2012-08-14 21:17 ` Andreas K. Huettel
1 sibling, 1 reply; 25+ messages in thread
From: Richard Yao @ 2012-08-14 16:09 UTC (permalink / raw
To: gentoo-project; +Cc: gentoo-bsd@lists.gentoo.org, council
[-- Attachment #1: Type: text/plain, Size: 309 bytes --]
On 08/14/2012 10:01 AM, Ulrich Mueller wrote:
> * Mandate GNU find
> http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=472690942e14f63f1b1f3a5681976a59539ea3f8
> https://bugs.gentoo.org/show_bug.cgi?id=384157
This will cause problems for Gentoo FreeBSD, which uses FreeBSD's find.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC
2012-08-14 14:01 ` Ulrich Mueller
2012-08-14 16:09 ` Richard Yao
@ 2012-08-14 21:17 ` Andreas K. Huettel
2012-08-14 21:35 ` Ciaran McCreesh
1 sibling, 1 reply; 25+ messages in thread
From: Andreas K. Huettel @ 2012-08-14 21:17 UTC (permalink / raw
To: gentoo-project; +Cc: gentoo-pms
[-- Attachment #1: Type: Text/Plain, Size: 907 bytes --]
Am Dienstag, 14. August 2012, 16:01:57 schrieb Ulrich Mueller:
>
> * make.defaults, use.force, use.mask, package.use, package.use.force
> and package.use.mask in ${repository_path}/profiles
> - Need profiles EAPI bump
> https://bugs.gentoo.org/show_bug.cgi?id=414817
>
With that in mind I'd like to propose that this feature is uncoupled from any
EAPI and discussed separately as add-on for all EAPI's.
Reason: it adds only new files, and does not modify the meaning of anything
existing. Waiting for a profile EAPI increase seems to be something like
waiting for Sankt Nimmerleinstag (in German, waiting for the nameday of a
saint that does not actually exist, i.e. hopelessly waiting forever).
Follow-up discussion on PMS please.
--
Andreas K. Huettel
Gentoo Linux developer
kde (team lead), sci, tex, arm, printing
dilfridge@gentoo.org
http://www.akhuettel.de/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC
2012-08-14 21:17 ` Andreas K. Huettel
@ 2012-08-14 21:35 ` Ciaran McCreesh
2012-08-14 21:55 ` Zac Medico
0 siblings, 1 reply; 25+ messages in thread
From: Ciaran McCreesh @ 2012-08-14 21:35 UTC (permalink / raw
To: gentoo-project
[-- Attachment #1: Type: text/plain, Size: 900 bytes --]
On Tue, 14 Aug 2012 23:17:56 +0200
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:
> Waiting for a profile EAPI increase seems to be
> something like waiting for Sankt Nimmerleinstag (in German, waiting
> for the nameday of a saint that does not actually exist, i.e.
> hopelessly waiting forever).
The only reason all this takes so long is because getting anything done
with EAPIs involves wasting months dealing with people who demand to
know why their favourite unicorn isn't there yet, why the EAPI process
isn't what they want it to be, why EAPIs have to exist at all, why we
have to care about stability, why we have to change things, why we
can't change things, etc etc.
If getting things quickly is a goal, then you should ask the Council to
look into reducing the amount of public discussion and concensus that's
necessary to deliver a new EAPI.
--
Ciaran McCreesh
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC
2012-08-14 21:35 ` Ciaran McCreesh
@ 2012-08-14 21:55 ` Zac Medico
2012-08-14 22:02 ` Ciaran McCreesh
2012-08-14 22:21 ` Andreas K. Huettel
0 siblings, 2 replies; 25+ messages in thread
From: Zac Medico @ 2012-08-14 21:55 UTC (permalink / raw
To: gentoo-project
On 08/14/2012 02:35 PM, Ciaran McCreesh wrote:
> On Tue, 14 Aug 2012 23:17:56 +0200
> "Andreas K. Huettel" <dilfridge@gentoo.org> wrote:
>> Waiting for a profile EAPI increase seems to be
>> something like waiting for Sankt Nimmerleinstag (in German, waiting
>> for the nameday of a saint that does not actually exist, i.e.
>> hopelessly waiting forever).
>
> The only reason all this takes so long is because getting anything done
> with EAPIs involves wasting months dealing with people who demand to
> know why their favourite unicorn isn't there yet, why the EAPI process
> isn't what they want it to be, why EAPIs have to exist at all, why we
> have to care about stability, why we have to change things, why we
> can't change things, etc etc.
>
> If getting things quickly is a goal, then you should ask the Council to
> look into reducing the amount of public discussion and concensus that's
> necessary to deliver a new EAPI.
It seems like there's some confusion here. Approving a new EAPI and
deciding to use a new EAPI in a given profile are two entirely different
things. If we want to us a new EAPI in a profile, we just have to deploy
it such that users are only exposed to that profile when they
consciously running `eselect profile` (and they can always revert back
to the previous profile if it turns out that their installed package
manager doesn't support the new profile).
--
Thanks,
Zac
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC
2012-08-14 21:55 ` Zac Medico
@ 2012-08-14 22:02 ` Ciaran McCreesh
2012-08-14 22:14 ` Zac Medico
2012-08-14 22:20 ` Michał Górny
2012-08-14 22:21 ` Andreas K. Huettel
1 sibling, 2 replies; 25+ messages in thread
From: Ciaran McCreesh @ 2012-08-14 22:02 UTC (permalink / raw
To: gentoo-project
[-- Attachment #1: Type: text/plain, Size: 864 bytes --]
On Tue, 14 Aug 2012 14:55:47 -0700
Zac Medico <zmedico@gentoo.org> wrote:
> It seems like there's some confusion here. Approving a new EAPI and
> deciding to use a new EAPI in a given profile are two entirely
> different things. If we want to us a new EAPI in a profile, we just
> have to deploy it such that users are only exposed to that profile
> when they consciously running `eselect profile` (and they can always
> revert back to the previous profile if it turns out that their
> installed package manager doesn't support the new profile).
There's still the issue that we haven't decided what [use] deps do when
they show up in profile files. We were sticking at 1 until we worked
that out.
(Personally I'm in favour of just not allowing use deps anywhere in
profiles, and requiring package manglers to enforce it.)
--
Ciaran McCreesh
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC
2012-08-14 22:02 ` Ciaran McCreesh
@ 2012-08-14 22:14 ` Zac Medico
2012-08-14 22:20 ` Michał Górny
1 sibling, 0 replies; 25+ messages in thread
From: Zac Medico @ 2012-08-14 22:14 UTC (permalink / raw
To: gentoo-project
On 08/14/2012 03:02 PM, Ciaran McCreesh wrote:
> On Tue, 14 Aug 2012 14:55:47 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
>> It seems like there's some confusion here. Approving a new EAPI and
>> deciding to use a new EAPI in a given profile are two entirely
>> different things. If we want to us a new EAPI in a profile, we just
>> have to deploy it such that users are only exposed to that profile
>> when they consciously running `eselect profile` (and they can always
>> revert back to the previous profile if it turns out that their
>> installed package manager doesn't support the new profile).
>
> There's still the issue that we haven't decided what [use] deps do when
> they show up in profile files. We were sticking at 1 until we worked
> that out.
>
> (Personally I'm in favour of just not allowing use deps anywhere in
> profiles, and requiring package manglers to enforce it.)
That sounds reasonable to me.
--
Thanks,
Zac
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC
2012-08-14 22:02 ` Ciaran McCreesh
2012-08-14 22:14 ` Zac Medico
@ 2012-08-14 22:20 ` Michał Górny
[not found] ` <20120815130131.1a3f10a8@googlemail.com>
2012-09-08 13:12 ` David Leverton
1 sibling, 2 replies; 25+ messages in thread
From: Michał Górny @ 2012-08-14 22:20 UTC (permalink / raw
To: gentoo-project; +Cc: ciaran.mccreesh
[-- Attachment #1: Type: text/plain, Size: 1638 bytes --]
On Tue, 14 Aug 2012 23:02:04 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> On Tue, 14 Aug 2012 14:55:47 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
> > It seems like there's some confusion here. Approving a new EAPI and
> > deciding to use a new EAPI in a given profile are two entirely
> > different things. If we want to us a new EAPI in a profile, we just
> > have to deploy it such that users are only exposed to that profile
> > when they consciously running `eselect profile` (and they can always
> > revert back to the previous profile if it turns out that their
> > installed package manager doesn't support the new profile).
>
> There's still the issue that we haven't decided what [use] deps do
> when they show up in profile files. We were sticking at 1 until we
> worked that out.
Ah, about that. It will be useful if [use] deps in package.mask worked
unlike in package.use.mask, thus giving us a tool to temporarily mask
packages which are broken only with given flags.
For example, likely it was potentially useful to do something like:
# something support with intel broken in this version
=media-libs/mesa-N.N.N[someflag,video_cards_intel,!video_cards_radeon,!video_cards_nvidia]
With meaning: mask mesa-N.N.N if 'someflag' and 'video_cards_intel' are
enabled, and 'video_cards_radeon' an 'video_cards_nvidia' are disabled.
This will make lives easier both for devs (who wouldn't have to
work-around this) and users (for those who will benefit from new mesa,
and those who will not upgrade and break their systems).
--
Best regards,
Michał Górny
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread[parent not found: <20120815130131.1a3f10a8@googlemail.com>]
* Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC
[not found] ` <20120815130131.1a3f10a8@googlemail.com>
@ 2012-08-15 12:11 ` Michał Górny
2012-08-15 12:12 ` Ciaran McCreesh
0 siblings, 1 reply; 25+ messages in thread
From: Michał Górny @ 2012-08-15 12:11 UTC (permalink / raw
To: gentoo-project; +Cc: ciaran.mccreesh
[-- Attachment #1: Type: text/plain, Size: 2001 bytes --]
On Wed, 15 Aug 2012 13:01:31 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> On Wed, 15 Aug 2012 00:20:21 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> > > There's still the issue that we haven't decided what [use] deps do
> > > when they show up in profile files. We were sticking at 1 until we
> > > worked that out.
> >
> > Ah, about that. It will be useful if [use] deps in package.mask
> > worked unlike in package.use.mask, thus giving us a tool to
> > temporarily mask packages which are broken only with given flags.
> >
> > For example, likely it was potentially useful to do something like:
> >
> > # something support with intel broken in this version
> > =media-libs/mesa-N.N.N[someflag,video_cards_intel,!video_cards_radeon,!video_cards_nvidia]
> >
> > With meaning: mask mesa-N.N.N if 'someflag' and 'video_cards_intel'
> > are enabled, and 'video_cards_radeon' an 'video_cards_nvidia' are
> > disabled.
> >
> > This will make lives easier both for devs (who wouldn't have to
> > work-around this) and users (for those who will benefit from new
> > mesa, and those who will not upgrade and break their systems).
>
> The issue there is whether the package mangler should try to solve
> that by tinkering with which flags are selected. The way Paludis
> implements it currently, it would just treat the package as being
> masked and wouldn't try the upgrade; I believe at one point Brian was
> talking about doing something clever with Pkgcore there and using
> that syntax to do use flag masking instead.
>
> Whichever route we go, there's also the UI question: how do we present
> this to users in a sensible way?
The intent is not to anything clever but just mask the package. Intel
users don't want mesa without support for their card; they simply don't
want the broken version at all.
It should be presented alike regular package.mask, with the whole
atom string.
--
Best regards,
Michał Górny
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC
2012-08-15 12:11 ` Michał Górny
@ 2012-08-15 12:12 ` Ciaran McCreesh
2012-08-15 12:23 ` Michał Górny
0 siblings, 1 reply; 25+ messages in thread
From: Ciaran McCreesh @ 2012-08-15 12:12 UTC (permalink / raw
To: Michał Górny; +Cc: gentoo-project
[-- Attachment #1: Type: text/plain, Size: 619 bytes --]
On Wed, 15 Aug 2012 14:11:55 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> > Whichever route we go, there's also the UI question: how do we
> > present this to users in a sensible way?
>
> The intent is not to anything clever but just mask the package. Intel
> users don't want mesa without support for their card; they simply
> don't want the broken version at all.
>
> It should be presented alike regular package.mask, with the whole
> atom string.
I'm not sure that it's that simple: what if a user has, say, intel
turned on only because it's on by default in profiles?
--
Ciaran McCreesh
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC
2012-08-15 12:12 ` Ciaran McCreesh
@ 2012-08-15 12:23 ` Michał Górny
0 siblings, 0 replies; 25+ messages in thread
From: Michał Górny @ 2012-08-15 12:23 UTC (permalink / raw
To: gentoo-project; +Cc: ciaran.mccreesh
[-- Attachment #1: Type: text/plain, Size: 977 bytes --]
On Wed, 15 Aug 2012 13:12:17 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> On Wed, 15 Aug 2012 14:11:55 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> > > Whichever route we go, there's also the UI question: how do we
> > > present this to users in a sensible way?
> >
> > The intent is not to anything clever but just mask the package.
> > Intel users don't want mesa without support for their card; they
> > simply don't want the broken version at all.
> >
> > It should be presented alike regular package.mask, with the whole
> > atom string.
>
> I'm not sure that it's that simple: what if a user has, say, intel
> turned on only because it's on by default in profiles?
In this particular case -- nothing, because he has by default other
card settings which make mesa don't trigger the bug. It was simply
a very weird bug which needed a simple solution to avoid spreading it
on users.
--
Best regards,
Michał Górny
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC
2012-08-14 22:20 ` Michał Górny
[not found] ` <20120815130131.1a3f10a8@googlemail.com>
@ 2012-09-08 13:12 ` David Leverton
2012-09-26 23:16 ` Brian Harring
1 sibling, 1 reply; 25+ messages in thread
From: David Leverton @ 2012-09-08 13:12 UTC (permalink / raw
To: gentoo-project
On 14 August 2012 23:20, Michał Górny <mgorny@gentoo.org> wrote:
> On Tue, 14 Aug 2012 23:02:04 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
>> There's still the issue that we haven't decided what [use] deps do
>> when they show up in profile files. We were sticking at 1 until we
>> worked that out.
>
> Ah, about that. It will be useful if [use] deps in package.mask worked
> unlike in package.use.mask, thus giving us a tool to temporarily mask
> packages which are broken only with given flags.
Do we have a verdict on this? What Michał suggests for package.mask
sounds OK to me, but use deps in package.use, package.use.mask, etc
could be rather nastier, and I'd be inclined to ban those unless
someone has a better idea.
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC
2012-09-08 13:12 ` David Leverton
@ 2012-09-26 23:16 ` Brian Harring
0 siblings, 0 replies; 25+ messages in thread
From: Brian Harring @ 2012-09-26 23:16 UTC (permalink / raw
To: gentoo-project
On Sat, Sep 08, 2012 at 02:12:40PM +0100, David Leverton wrote:
> On 14 August 2012 23:20, Micha?? G??rny <mgorny@gentoo.org> wrote:
> > On Tue, 14 Aug 2012 23:02:04 +0100
> > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> >> There's still the issue that we haven't decided what [use] deps do
> >> when they show up in profile files. We were sticking at 1 until we
> >> worked that out.
> >
> > Ah, about that. It will be useful if [use] deps in package.mask worked
> > unlike in package.use.mask, thus giving us a tool to temporarily mask
> > packages which are broken only with given flags.
>
> Do we have a verdict on this? What Micha?? suggests for package.mask
> sounds OK to me, but use deps in package.use, package.use.mask, etc
> could be rather nastier, and I'd be inclined to ban those unless
> someone has a better idea.
Use deps in all *.mask are already banned; whether by spec or
convention- when they were added the potential was known, and stated
as "don't do that".
If we're going to try doing it now, analysis needs to be done to see
what fallout there is *before trying to change the fucking thing*.
Offhand, I'd strongly bet no PM will handle a use dep atom in
package.mask now; as for *.use.* abuse of use deps, that's frankly
worse- it's chained deps, "if this use configuration, mask that flag".
That's hell on wheels for the PM to implement.
Personally, I'd like to see 'dev-util/diffball[debug]' usable in
package.use.mask (instead of dev-util/diffball debug), but it's not a
backwards compatible change w/ existing PMs.
Either way, the verdict is "can't go anywhere till compatibility is
figured out" :P
~harring
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC
2012-08-14 21:55 ` Zac Medico
2012-08-14 22:02 ` Ciaran McCreesh
@ 2012-08-14 22:21 ` Andreas K. Huettel
2012-08-14 22:29 ` Zac Medico
1 sibling, 1 reply; 25+ messages in thread
From: Andreas K. Huettel @ 2012-08-14 22:21 UTC (permalink / raw
To: gentoo-project
[-- Attachment #1: Type: Text/Plain, Size: 1299 bytes --]
Am Dienstag, 14. August 2012, 23:55:47 schrieb Zac Medico:
> It seems like there's some confusion here. Approving a new EAPI and
> deciding to use a new EAPI in a given profile are two entirely different
> things. If we want to us a new EAPI in a profile, we just have to deploy
> it such that users are only exposed to that profile when they
> consciously running `eselect profile` (and they can always revert back
> to the previous profile if it turns out that their installed package
> manager doesn't support the new profile).
Yeah but... either
1) we use such an obscure profile that noone actually notices the change, or
2) we try to change something in the "big, well-known profiles",
and then we're back at the start.
So what good is including a feature in a new profile if there is no way to
make it visible to "the users" in general?
Also, in this particular case, "stable use masking" is useful because it makes
stabilization possible/simpler in cases where otherwise this would lead to
broken dependencies (stable depending on ~arch). If only one small sub-profile
provides the feature, we lose its whole advantage.
--
Andreas K. Huettel
Gentoo Linux developer
kde (team lead), sci, tex, arm, printing
dilfridge@gentoo.org
http://www.akhuettel.de/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-project] Council meeting: Tuesday 14 August 2012, 19:00 UTC
2012-08-14 22:21 ` Andreas K. Huettel
@ 2012-08-14 22:29 ` Zac Medico
0 siblings, 0 replies; 25+ messages in thread
From: Zac Medico @ 2012-08-14 22:29 UTC (permalink / raw
To: gentoo-project
On 08/14/2012 03:21 PM, Andreas K. Huettel wrote:
> Am Dienstag, 14. August 2012, 23:55:47 schrieb Zac Medico:
>> It seems like there's some confusion here. Approving a new EAPI and
>> deciding to use a new EAPI in a given profile are two entirely different
>> things. If we want to us a new EAPI in a profile, we just have to deploy
>> it such that users are only exposed to that profile when they
>> consciously running `eselect profile` (and they can always revert back
>> to the previous profile if it turns out that their installed package
>> manager doesn't support the new profile).
>
> Yeah but... either
> 1) we use such an obscure profile that noone actually notices the change, or
> 2) we try to change something in the "big, well-known profiles",
> and then we're back at the start.
>
> So what good is including a feature in a new profile if there is no way to
> make it visible to "the users" in general?
You do it in all the new profiles, and deprecate the old profiles. Users
see the profile deprecation notice (or news item or other announcement)
and upgrade their profile.
> Also, in this particular case, "stable use masking" is useful because it makes
> stabilization possible/simpler in cases where otherwise this would lead to
> broken dependencies (stable depending on ~arch). If only one small sub-profile
> provides the feature, we lose its whole advantage.
Yeah, that's why I'm saying to do it in *all* new profiles and deprecate
the old ones.
--
Thanks,
Zac
^ permalink raw reply [flat|nested] 25+ messages in thread