On 15:17 Fri 17 Apr , Donnie Berkholz wrote:
> If you have something you'd wish for us to chat about, maybe even vote
> on, let us know! Simply reply to this e-mail for the whole Gentoo dev
> list to see.
I've got a few items pending that I would like to propose. It should be
clear that there are way too many topics in this list for a single
meeting, so we'll have to prioritize a bit and discuss on list in
advance as much as possible.
Feel free to reply to this email regarding any of the below items.
Please change the subject so it's easier to parse through the
subthreads.
GLEP 54: Dealing with live SCM packages
---------------------------------------
Goal: Vote on approval of GLEP 54.
Handling EAPI versioning in a forwards-compatible way
-----------------------------------------------------
Goal: Vote on the implementation for the problem solved in GLEP 55.
EAPI=3: Progress update
-----------------------
Zac agreed to have the feature list implemented by this meeting, April
23. Assuming this will be the case, what else is left?
EAPI 4: Inclusion of prefix-related variables
---------------------------------------------
Fabian Groffen wrote:
I would like the council to discuss the addition of three variables to
EAPI3.
- EPREFIX
The offset prefix of a Gentoo Prefix installation. When Gentoo Prefix
is not used, ${EPREFIX} should be "".
This variable should be available everywhere.
- EROOT
The offset prefix appended to ${ROOT}, e.g. ${ROOT%/}${EPREFIX}/
This variable is available where ROOT is, following PMS: pkg_*
- ED
The offset prefix appended to ${D}, e.g. ${D%/}${EPREFIX}/
This variable is available where D is, following PMS: src_install
While the first variable (EPREFIX) can be set using an eclass, the
latter two need to be set by the package manager. In particular ED,
because the value of D might not be known. EROOT and ED are convenience
variables. Making them available already now, even though initialised
as ROOT and D respectively, allows Prefix enabled ebuilds to be shared
between gentoo-x86 and Prefix trees without modifications.
Goal: Get opinions from council members.
Time allotted: 15 minutes
EAPI 4: Inclusion of "mtime preservation"
-----------------------------------------
Ulrich Mueller proposed this for inclusion.
Consider inclusion of "mtime preservation" (see bug 264130, and the
thread "Preserving mtimes for EAPI3" in this ML).
As I see it, there are three options:
A. Always preserve timestamps when merging from D to ROOT, what was my
original suggestion. Portage and Pkgcore already comply with this.
B. Preserve timestamps, but optionally allow the package manager to update
"old" ones. This is the suggestion from comment #12. Again, Portage and
Pkgcore would be compliant already (since updating mtimes would be
optional).
C. As B, but with mandatory updating of "old" mtimes. For this, all three
package managers would have to be changed.
Goal: Bring up concerns. Vote on this.
Time allotted: 10 minutes
Portage changing behavior in ebuild-visible ways
------------------------------------------------
David Leverton wrote:
I would like the Council to discuss the matter of Portage repeatedly
changing behaviour in ebuild-visible ways without an EAPI bump or even
an announcement that anything changed. Notable examples include .lzma
support in unpack (bug 207193), the change in pkg_* phase ordering (bug
222721) and the preservation of timestamps during merge (bug 264130).
It is quite frustrating to spend considerable effort determining
Portage's behaviour and matching it in Paludis, only to find a few
months later that Portage changed and now users are getting broken
packages if not broken systems because ebuilds are starting to rely on
the new rules.
Goal: David proposes having a policy that this won't happen in the
future or admitting that we don't really care.
Time allotted: 15 minutes
--
Thanks,
Donnie
Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com
|
