[gentoo-council] Agenda for October meeting

[gentoo-council] Agenda for October meeting

[Petteri Räty]

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

I am charge of creating the agenda for the October meeting. Silly me for
thinking that it would involve acting in October as there's now under
two weeks to the meeting. Anyway please submit your items by replying to
this mail.

Regards,
Petteri


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

Re: [gentoo-council] Agenda for October meeting

[Ulrich Mueller]

>>>>> On Thu, 01 Oct 2009, Petteri Räty wrote:

> I am charge of creating the agenda for the October meeting. Silly me
> for thinking that it would involve acting in October as there's now
> under two weeks to the meeting. Anyway please submit your items by
> replying to this mail.

1. I'd like to see a short progress report on EAPI 3 implementation
   in Portage.

2. In case that the above isn't very close to a release, I ask the
   council to vote on the following:

   EAPI 3 is reopened for the purpose of including one sole feature,
   namely preservation of file modification times, as outlined in
   bug 264130, option B of comment 26 [1]. Both Portage and Pkgcore
   already comply with this, so it would be zero implementation cost.

Ulrich

[1] <http://bugs.gentoo.org/show_bug.cgi?id=264130#c26>

Re: [gentoo-council] Agenda for October meeting

[Ciaran McCreesh]

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

On Thu, 1 Oct 2009 16:22:01 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:
>    EAPI 3 is reopened for the purpose of including one sole feature,
>    namely preservation of file modification times, as outlined in
>    bug 264130, option B of comment 26 [1]. Both Portage and Pkgcore
>    already comply with this, so it would be zero implementation cost.

Why go with an inferior solution? Why not go with a solution that
requires the package manager to fix broken mtimes?

Also, what are the rules regarding this and things like stripping and
other fixes and changes that the package manager performs upon files
before merging them?

-- 
Ciaran McCreesh

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

Re: [gentoo-council] Agenda for October meeting

[Ulrich Mueller]

>>>>> On Thu, 1 Oct 2009, Ciaran McCreesh wrote:

>> EAPI 3 is reopened for the purpose of including one sole feature,
>> namely preservation of file modification times, as outlined in
>> bug 264130, option B of comment 26 [1]. Both Portage and Pkgcore
>> already comply with this, so it would be zero implementation cost.

> Why go with an inferior solution? Why not go with a solution that
> requires the package manager to fix broken mtimes?

Because it would be non-zero implementation cost for Portage, so
probably out of question for EAPI 3. And it's not at all clear if the
solution is inferior. Since half a year, nobody cared to answer the
question of comment 25 of mentioned bug.

But if you want, the council can also vote if it should be option
A (current Portage and Pkgcore behaviour, all mtimes are preserved),
B (optional update of "old" mtimes), or C (mandatory update).

@betelgeuse: Could you please add this to the agenda, too?

> Also, what are the rules regarding this and things like stripping
> and other fixes and changes that the package manager performs upon
> files before merging them?

This is outside the scope of this proposal, and (at least for now) I'm
not going to work anything out.

Ulrich

Re: [gentoo-council] Agenda for October meeting

[Ciaran McCreesh]

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

On Thu, 1 Oct 2009 16:49:43 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:
> > Why go with an inferior solution? Why not go with a solution that
> > requires the package manager to fix broken mtimes?
> 
> Because it would be non-zero implementation cost for Portage, so
> probably out of question for EAPI 3.

It's cheap, and it's doing it the right way. If we were to design the
feature up-front rather than going with whatever Portage does, we'd go
with mtime fixing.

> And it's not at all clear if the solution is inferior. Since half a
> year, nobody cared to answer the question of comment 25 of mentioned
> bug.

Because comment 25 is entirely missing the point. The objection is not
to preservation. The objection is to pure preservation with no handling
for dodgy mtimes.

> > Also, what are the rules regarding this and things like stripping
> > and other fixes and changes that the package manager performs upon
> > files before merging them?
> 
> This is outside the scope of this proposal, and (at least for now) I'm
> not going to work anything out.

It's not. It's a necessary part of the proposal. You need to define the
behaviour here, since if you don't, we're back to ebuilds relying upon
undefined behaviour.

What you're effectively saying by ignoring this is "mtimes must be
preserved, except when they're not". That isn't good enough, since it
would be entirely legal for a package manager to not do any
preservation at all then. Alternatively, you're saying "mtimes must
always be preserved", in which case Portage isn't compliant. This isn't
something you can just ignore.

-- 
Ciaran McCreesh

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