On P, 2009-04-12 at 20:59 +0100, Ciaran McCreesh wrote: > I've got the EAPI 3 branch for PMS more or less ready: > > http://github.com/ciaranm/pms/tree/eapi-3 > > The provisional included feature list is everything that was ready > before the deadline. > > Before the next Council meeting (ideally a week before, so we've got > time to get the questions worked out), I'd appreciate it if every > Council member could go through each item on the list below, check its > description in PMS (Appendix E has a handy list of links to the > relevant text, or look for the boxed labels in the margin) and > provisionally mark it as one of: > > * critical: EAPI 3 needs to be held up until this feature is in Portage. > > * yes: This feature should be in EAPI 3, but can be dropped if it turns > out it's going to take ages to get into Portage. > > * no: This feature shouldn't be in EAPI 3. > > * whatever: You have no strong opinion on whether this feature should > be in EAPI 3. > > * query: You have questions about this feature, or you think parts of > it need discussion, or you've found a mistake in the PMS draft. > > I'll try to address any queries as they come so people can update their > opinions. > > I'd also appreciate any review of wording features from anyone else. > There are probably still a few holes. > > Hopefully we can get a final list decided upon and provisionally > approved by the next Council meeting, and then as soon as Portage is > ready to go we can merge everything into PMS proper and get a signed > approval tag as we did for EAPI 2. > > Here's the list: > > * PKG-PRETEND
critical
> * SLOT-OPERATOR-DEPS
query.
Needs discussion I can't conduct on-list today anymore (middle of night
already) as I need to sit down and think this through more heavily, also
in light of some recent discussion with dev-zero. Will bring to list
ASAP. Mostly relates to syntax considerations.
An outstanding problem to me as a package maintainer is the lack of
means to know which slot the PM actually picked for the package, as some
of my co-maintained packages have no use of := if it can't know which
version was picked to act accordingly in src_configure.
> * USE-DEP-DEFAULTS
critical
> * DEFINED-PHASES
yes. critical for PKG-PRETEND
> * PROPERTIES
yes
> * SRC-INSTALL
query/yes; but the default src_install maybe shouldn't be doing the file
exists and is greater than zero check, because dodoc in portage already
does that. Maybe formalize that and leave that check for dodoc
responsibility and don't bother checking twice?
> * CONTROLLABLE-COMPRESS
yes
> * DODOC
yes
> * DOINS
query. Lacks specification of what "correct" is in "must correctly
handle symlinks when installing recursively", so can't judge.
Yes, I know a mail thread addressed it, but that doesn't count in what
goes into an approved PMS.
I suppose it's mostly understood what it means, but it wouldn't hurt for
a specification to be explicit.
Also, would be interesting to know what sanity checks one would want to
apply in the future for absolute path symlinks in case they do not start
with $EPREFIX (don't honor --prefix)? Just curious for the future on
this one.
> * ANY-USE
no
> * BANNED-COMMANDS
no for dohard
whatever for dosed
dohard works fine now in portage when it technically can. The wording in
section 12.3.3 for dohard should be changed however to not give a
guarantee but a "best effort", as if when installed on the _live system_
they end up on a separate partition it is not technically possible.
However a common use case can be to do it in the same directory and it
should work fine then, if PM makes sure the hard link is not lost when
they get potentially copied/moved around between various partition in
$PORTAGE_TMPDIR, $D and $ROOT, which portage does since a few months
now.
This best effort support already needs to exist to handle cases like
dev-util/git provided hard links in $libexec/git-core, so this is just a
function to do the same in ebuilds.
I already wrote about this on 9th April in the "Ideas for a (fast)
EAPI=3" thread, but got no replies.
> * DOEXAMPLE
no. perhaps after a "query" phase might lean more towards "whatever"
Additionally the PMS draft has a typo:
newinclude
As above, for doexample. Only in EAPIs listed in table 12.7
newinclude is listed twice; that one should be titled newexample
> * DOINCLUDE
no
> * UNPACK-EXTENSIONS
yes (query), if we are sure we can rely on the xzdec arguments and such
to remain the same once released.
> * ECONF-OPTIONS
query
--disable-dependency-tracking has other implications than it being
allowed to be passed to ./configure or not - such as dependency tracking
being, well, disabled and the affects of that in face of any outside
influences to headers used by it from the system, when compared to the
case when dependency tracking is enabled. Such as when a separate
(possibly parallel) install step kicks in.
Olivier Crête also has an outstanding comment about a maintainer
possibly not wanting that disabled in case of patches applied. Could use
some elaboration on that thought, or comments in replies.
--enable-fast-install is completely new to me for consideration under
EAPI-3. Maybe I just missed it when reading PMS draft before, and it
wasn't listed in the other summaries.
It is libtool specific and already the default.
Don't see any reason to specify this, as only configure's with libtool
usage (LT_INIT in configure.ac) have that option, and enabling it is the
default unless package upstream has specifically disabled it with an
option to LT_INIT m4 macro. Therefore a definite "no" for
--enable-fast-install.
> * PKG-INFO
query
Same question as Petteri
but also what if we want to display information based on saved
environment? Any suggestion into the spec which way to use for checking
if the package in question is already installed or not?
> * PROFILE-IUSE-INJECTION
query. need to review a bit further for myself in relation to profile
set implicit stuff and emerge --newuse behaviour and output
> * AA
whatever
> * KV
whatever
> * REPLACE-VERSION-VARS
query
need to think more through for myself, also possibly somewhat in
relation to slot operators
> * S-WORKDIR-FALLBACK
whatever
> * UNPACK-IF-COMPRESSED
query
I think the spec draft reads that it will be an error to pass regular
files to unpack --if-compressed. That seems backwards.
Still a bit unsure about the default non-argument case choice.
> * RDEPEND-DEPEND
yes
> * DIE-ON-FAILURE
whatever
> * NONFATAL
whatever
--
Mart Raudsepp
Gentoo Developer
Mail: [email protected]
Weblog: http://planet.gentoo.org/developers/leio
signature.asc
Description: This is a digitally signed message part
