Gentoo Archives: gentoo-council

From: Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>
To: Ulrich Mueller <ulm@g.o>
Cc: gentoo-council@l.g.o
Subject: Re: [gentoo-council] Agenda for October meeting
Date: Thu, 01 Oct 2009 14:59:53
Message-Id: 20091001155924.1eb80be8@snowmobile
In Reply to: Re: [gentoo-council] Agenda for October meeting by Ulrich Mueller
On Thu, 1 Oct 2009 16:49:43 +0200
Ulrich Mueller <ulm@g.o> 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


File name MIME type
signature.asc application/pgp-signature