[gentoo-dev] One-Day Gentoo Council Reminder for September

[gentoo-dev] One-Day Gentoo Council Reminder for September

[Mike Frysinger]

This is your one-day friendly reminder !  The monthly Gentoo Council
meeting is tomorrow in #gentoo-council on irc.freenode.net.  See the
channel topic for the exact time (but it's probably 2000 UTC).

If you're supposed to show up, please show up.  If you're not supposed
to show up, then show up anyways and watch your Council monkeys dance
for you.

For more info on the Gentoo Council, feel free to browse our homepage:
http://www.gentoo.org/proj/en/council/

Re: [gentoo-dev] One-Day Gentoo Council Reminder for September

[Donnie Berkholz]

[-- Attachment #1.1: Type: text/plain, Size: 796 bytes --]

On 03:03 Wed 10 Sep     , Mike Frysinger wrote:
> This is your one-day friendly reminder !  The monthly Gentoo Council
> meeting is tomorrow in #gentoo-council on irc.freenode.net.  See the
> channel topic for the exact time (but it's probably 2000 UTC).

Here's the agenda. I'm eagerly awaiting submission of EAPI 2, whenever 
folks are ready.

To track Tom Wesley's request that we document the appeals process, I 
opened http://bugs.gentoo.org/show_bug.cgi?id=237381. We'll discuss it 
on the gentoo-council mailing list.

BTW, sorry about the delay getting old meetings posted. My wife & I just 
had a baby last week and things have been hectic around here for a 
while.

-- 
Thanks,
Donnie

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

[-- Attachment #1.2: 20080911-agenda.txt --]
[-- Type: text/plain, Size: 811 bytes --]

Roll call
=========
betelgeuse 
dberkholz  
dertobi123 
halcy0n    
jokey      
lu_zero    


First
=====

Filling the empty slot
----------------------
Last time there was an empty slot, we voted on whether to fill the slot 
with the next person from the original rankings. Let's do the same this 
time. It's Cardoe.

Goal: Vote whether to approve Cardoe for the empty council slot.


Old topics
==========

PMS as a draft standard of EAPI 0
---------------------------------
Next meeting is Sept 11, and we request that everyone involved with PM 
development or the spec email gentoo-dev about any issues with it. 
Otherwise, it's likely to be approved as a draft standard.

Goal: Vote whether to approve PMS as a draft standard of EAPI 0.


New topics
==========

None.

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

Re: [gentoo-dev] One-Day Gentoo Council Reminder for September

[Zac Medico]

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

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

Donnie Berkholz wrote:
> Here's the agenda. I'm eagerly awaiting submission of EAPI 2, whenever 
> folks are ready.

I've updated the EAPI 2 draft to remove the eapi* functions and the
gitweb unpack extension as mentioned earlier in Jorge's email [1].
The html version of the draft is posted in my dev space [2] and is
also attached directly to this email. All of the extensions are
summarized below:

 * The 'doman' helper function recognizes language codes in man page
   source files, and uses them to generate an appropriate
   installation path.

 * The meaning of the !atom blocker syntax now implies that
   temporary simultaneous installation of conflicting packages is
   allowed [3].

 * A new !!atom blocker syntax is now supported, for use in special
   cases in which temporary simultaneous installation of conflicting
   packages should not be allowed.

 * Dependency atoms can be constrained to match specific USE flag
   states, including USE conditional expressions embedded within
   the atoms themselves.

 * SRC_URI supports a syntax extension which allows customization
   of output file names by using a "->" operator.

 * A new src_prepare phase function is called after src_unpack.

 * The old src_compile phase function is split into separate
   src_configure and src_compile fuctions.

 * Default phase function implementations for the current EAPI are
   accessible via a function having a name that begins with default_
   and ends with the respective phase function name.

 * The default phase function implementation for the currently
   executing phase is accessible as a function named 'default'.

[1]
http://archives.gentoo.org/gentoo-dev/msg_2124e5ac0da4c1928d96a7186a81a0a3.xml
[2] http://dev.gentoo.org/~zmedico/portage/eapi/eapi-2-draft.html

- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjIvigACgkQ/ejvha5XGaM8VACgtdpQQaHg6M/ZVH6sYvrTdeEF
PfwAoLJx1wn5le/0GZReFGaFQM7F5RND
=SY0M
-----END PGP SIGNATURE-----

[-- Attachment #2: eapi-2-draft.html --]
[-- Type: text/html, Size: 13743 bytes --]

[-- Attachment #3: eapi-2-draft.html.sig --]
[-- Type: application/octet-stream, Size: 72 bytes --]

Re: [gentoo-dev] One-Day Gentoo Council Reminder for September

[Ciaran McCreesh]

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

On Wed, 10 Sep 2008 23:43:54 -0700
Zac Medico <zmedico@gentoo.org> wrote:
> [2] http://dev.gentoo.org/~zmedico/portage/eapi/eapi-2-draft.html

By table 6.11, are you implying that you consider the new pkg_ phase
order to be part of EAPI 2?

Really, Portage needs to revert the order and go back to the way it
used to be for all EAPIs. The change breaks lots of existing ebuilds
(you claim you've probably fixed everything in ::gentoo, but you don't
know that and you've definitely not fixed overlays), including ebuilds
using a common documented technique recommended by the devmanual.

If you want the new pkg_* ordering to go through at all, it really
needs a lengthy discussion on its own and it mustn't apply to any
action that involves any existing EAPI.

I'd like the Council to say that for anything involving EAPIs 0, 1 or 2
we stick to the pkg_* phase ordering we've used years.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] One-Day Gentoo Council Reminder for September

[Robert Buchholz]

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

On Thursday 11 September 2008, Ciaran McCreesh wrote:
> On Wed, 10 Sep 2008 23:43:54 -0700
>
> Zac Medico <zmedico@gentoo.org> wrote:
> > [2] http://dev.gentoo.org/~zmedico/portage/eapi/eapi-2-draft.html
>
> By table 6.11, are you implying that you consider the new pkg_ phase
> order to be part of EAPI 2?
>
> Really, Portage needs to revert the order and go back to the way it
> used to be for all EAPIs. The change breaks lots of existing ebuilds
> (you claim you've probably fixed everything in ::gentoo, but you
> don't know that and you've definitely not fixed overlays), including
> ebuilds using a common documented technique recommended by the
> devmanual.
>
> If you want the new pkg_* ordering to go through at all, it really
> needs a lengthy discussion on its own and it mustn't apply to any
> action that involves any existing EAPI.
>
> I'd like the Council to say that for anything involving EAPIs 0, 1 or
> 2 we stick to the pkg_* phase ordering we've used years.

What is the change of order you witnessed in table 6.11 of the draft? 
Comparing that to the PMS on [3], the order looks identical to me 
(except for the two new phases). Am I missing something?


Robert

[3] http://dev.gentoo.org/~coldwind/pms.pdf Section 10.2

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

Re: [gentoo-dev] One-Day Gentoo Council Reminder for September

[Santiago M. Mola]

On Thu, Sep 11, 2008 at 4:55 PM, Robert Buchholz <rbu@gentoo.org> wrote:
> On Thursday 11 September 2008, Ciaran McCreesh wrote:
>> On Wed, 10 Sep 2008 23:43:54 -0700
>>
>> Zac Medico <zmedico@gentoo.org> wrote:
>> > [2] http://dev.gentoo.org/~zmedico/portage/eapi/eapi-2-draft.html
>>
>> By table 6.11, are you implying that you consider the new pkg_ phase
>> order to be part of EAPI 2?
>>
>> Really, Portage needs to revert the order and go back to the way it
>> used to be for all EAPIs. The change breaks lots of existing ebuilds
>> (you claim you've probably fixed everything in ::gentoo, but you
>> don't know that and you've definitely not fixed overlays), including
>> ebuilds using a common documented technique recommended by the
>> devmanual.
>>
>> If you want the new pkg_* ordering to go through at all, it really
>> needs a lengthy discussion on its own and it mustn't apply to any
>> action that involves any existing EAPI.
>>
>> I'd like the Council to say that for anything involving EAPIs 0, 1 or
>> 2 we stick to the pkg_* phase ordering we've used years.
>
> What is the change of order you witnessed in table 6.11 of the draft?
> Comparing that to the PMS on [3], the order looks identical to me
> (except for the two new phases). Am I missing something?
>
>
> Robert
>
> [3] http://dev.gentoo.org/~coldwind/pms.pdf Section 10.2
>

Previously, the order was different for upgrading/downgrading
packages. You can see a summary of the problem in bug #235020 [1]. I
sent a note to @-dev [2] with a list of all packages *in the tree*
which were affected by the most common problem of the order change
(using has_version in pkg_postinst), all of them were quickly fixed by
Zac. But there may be more packages affected not included there.

[1] https://bugs.gentoo.org/show_bug.cgi?id=226505
[2] http://archives.gentoo.org/gentoo-dev/msg_27feec8fc563e406b174386d24c39fdc.xml

Regards,
--
Santiago M. Mola
Jabber ID: cooldwind@gmail.com

Re: [gentoo-dev] One-Day Gentoo Council Reminder for September

[Zac Medico]

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

Ciaran McCreesh wrote:
> On Wed, 10 Sep 2008 23:43:54 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
>> [2] http://dev.gentoo.org/~zmedico/portage/eapi/eapi-2-draft.html
> 
> By table 6.11, are you implying that you consider the new pkg_ phase
> order to be part of EAPI 2?

No, I consider the phase order change [1] to be outside the scope of
EAPI.

> Really, Portage needs to revert the order and go back to the way it
> used to be for all EAPIs. The change breaks lots of existing ebuilds
> (you claim you've probably fixed everything in ::gentoo, but you don't
> know that and you've definitely not fixed overlays), including ebuilds
> using a common documented technique recommended by the devmanual.

The breakage to ebuilds, if they are broken in any way, seems to be
non-critical in the vast majority of cases since the new phase order
is identical to the phase order that portage has always used when
replacing a given ebuild with another ebuild of the same version [1].

I consider the use of has_version calls in pkg_postinst to detect
the previous installed version of a package, as suggested in
devmanual [2], to be an illogical or counter-intuitive approach. The
 counter-intuitive nature of the approach explains why it was only
used in a small fraction of the ebuilds in the tree. Ebuilds that
used this approach were easily fixed by moving the has_version calls
to pkg_preinst and storing the results in environment variables.

When moving has_version calls from pkg_postinst to pkg_preinst for
all ebuilds in the tree, I noticed that the calls were typically
used to trigger einfo or ewarn messages. So, the majority of such
breakage simply resulted in failure to generate einfo or ewarn
messages in some upgrade or downgrade scenarious.

> If you want the new pkg_* ordering to go through at all, it really
> needs a lengthy discussion on its own and it mustn't apply to any
> action that involves any existing EAPI.

I think it's worthwhile to have consistent phase ordering across all
EAPIs. Consider an upgrade from EAPI 0 to EAPI 2. If the phase order
is consistent across all EAPIs, as implemented in
>=sys-apps/portage-2.1.5, then the order of phase execution order is
uniform and unambiguous:

  Upgrade from EAPI 0 to EAPI 2

    pkg_preinst   (EAPI 2)
    pkg_prerm     (EAPI 0)
    pkg_postinst  (EAPI 0)
    pkg_postinst  (EAPI 2)

If the phase order varies from one EAPI to another, as you suggest,
then it seems like the phase order will not be uniform and the
logical order will be ambiguous in some cases since it will depend
upon both the EAPI of the original ebuild and the EAPI of the ebuild
that will replace it:

  Upgrade from EAPI 0 to EAPI 2 (maybe ambiguous):

    pkg_preinst  (EAPI 2)
    pkg_postinst (EAPI 2)
    pkg_prerm    (EAPI 0)
    pkg_postrm   (EAPI 0)

  Downgrade from EAPI 0 to EAPI 2 (certainly ambiguous):

    One conceivable order:

      pkg_preinst  (EAPI 0)
      pkg_postinst (EAPI 0)
      pkg_prerm    (EAPI 2)
      pkg_postrm   (EAPI 2)

    Another conceivable order:

      pkg_preinst  (EAPI 0)
      pkg_prerm    (EAPI 2)
      pkg_postrm   (EAPI 2)
      pkg_postinst (EAPI 0)

  Upgrade from EAPI 2 to EAPI 2 (unambiguous):

    pkg_preinst   (EAPI 2)
    pkg_prerm     (EAPI 2)
    pkg_postinst  (EAPI 2)
    pkg_postinst  (EAPI 2)

> I'd like the Council to say that for anything involving EAPIs 0, 1 or 2
> we stick to the pkg_* phase ordering we've used years.

Given that the phase order used in <sys-apps/portage-2.1.5 varies
depending on whether or not the new and old version are identical
[1], I consider the uniformity introduced by the new phase order to
be a change that is well worth keeping. Given the small number of
problems that have been discovered in practice, tracked by bug
226505 [3], I believe that the potential problems have proven to be
negligible.

[1]
http://dev.gentoo.org/~zmedico/portage/doc/portage.html#package-ebuild-phases-previous-installed
[2] http://bugs.gentoo.org/show_bug.cgi?id=226419
[3] http://bugs.gentoo.org/show_bug.cgi?id=226505
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjJPGAACgkQ/ejvha5XGaP4HQCfQvElOLBiFevxpFGIvXTHXwRv
rrsAoI8uHLdEpztPViR6q9WYWLp3suJk
=NQRa
-----END PGP SIGNATURE-----

[gentoo-dev] Re: Phase order changes (was: One-Day Gentoo Council Reminder for September)

[Ulrich Mueller]

>>>>> On Thu, 11 Sep 2008, Zac Medico wrote:

> I think it's worthwhile to have consistent phase ordering across all
> EAPIs. Consider an upgrade from EAPI 0 to EAPI 2. If the phase order
> is consistent across all EAPIs, as implemented in
> >=sys-apps/portage-2.1.5, then the order of phase execution order is
> uniform and unambiguous:

>   Upgrade from EAPI 0 to EAPI 2

>     pkg_preinst   (EAPI 2)
>     pkg_prerm     (EAPI 0)
>     pkg_postinst  (EAPI 0)

This should read "pkg_postrm" I think?

>     pkg_postinst  (EAPI 2)

> [...]

> Given that the phase order used in <sys-apps/portage-2.1.5 varies
> depending on whether or not the new and old version are identical
> [1], I consider the uniformity introduced by the new phase order to
> be a change that is well worth keeping. Given the small number of
> problems that have been discovered in practice, tracked by bug
> 226505 [3], I believe that the potential problems have proven to be
> negligible.

+1

In some situations involving eclasses, the new phase order avoids some
problems. pkg_postrm may call a function of an eclass saved with the
old package in the VDB, and it may have advantages if you can clean up
things in pkg_postinst of the new version.

For example, the Emacs team had quite some headache due to pkg_postrm
running after pkg_postinst, leading to complicated code in the present
version of elisp-common.eclass. This wouldn't have been necessary if
the new phase order already was in effect at that time. See ref. [4]
for further details.

Ulrich

[4] http://bugs.gentoo.org/show_bug.cgi?id=210764#c3

Re: [gentoo-dev] One-Day Gentoo Council Reminder for September

[Bo Ørsted Andresen]

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

On Thursday 11 September 2008 17:42:25 Zac Medico wrote:
> Ebuilds that used this approach were easily fixed by moving the has_version 
> calls to pkg_preinst and storing the results in environment variables.

Which breaks with any portage old enough to not properly support storing 
environment variables between phases (<2.1.4.4?).

-- 
Bo Andresen

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

Re: [gentoo-dev] One-Day Gentoo Council Reminder for September

[Zac Medico]

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

Bo Ørsted Andresen wrote:
> On Thursday 11 September 2008 17:42:25 Zac Medico wrote:
>> Ebuilds that used this approach were easily fixed by moving the has_version 
>> calls to pkg_preinst and storing the results in environment variables.
> 
> Which breaks with any portage old enough to not properly support storing 
> environment variables between phases (<2.1.4.4?).

No, it works fine with older versions of portage. The environment
handling improvements in >=portage-2.1.4 make it possible to load
environment.bz2 but this feature is not required for environment
persistence between pkg_preinst and pkg_postinst.

- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjJcckACgkQ/ejvha5XGaPMVACeIAik+RdrjDxky/8pqGmYwjM/
l3cAn2VS7hFO82GpCbqMEkxhUmaFHq4T
=YdcC
-----END PGP SIGNATURE-----