Duncan wrote:
<snip>
> our users -- Gentoo sysadmins by another name.
THANK YOU! Finally someone said it (and explained it better than I could.)
All our users-- the ones who deal with the glitches that can arise in a
source distro which binary users never see-- have the skill level of an
admin anywhere else.
It might take someone two or three months to get the basics on Gentoo, but
if you can manage a manual install and maintain a Gentoo box, no-one should
be sneering at you (especially as they started out knowing nothing too.)
> Without that clearly stated, I was conflating the two
> possible changes, the one given by the GLEP, and the one left unspec-ed,
> and thus reserved for the future and/or other non-Gentoo usage,
> extensions /other/ than .ebuild[-<suffix>].
>
Interesting: it brings up the possibility of simply using another extension
for files with eapi encoded in the name, and leaving the existing .ebuild
to continue as is.
PMs which don't support versioning would ignore them, since they're
not .ebuild, and existing tools would need the same changes as
with .ebuild-foo; .eapi-foo ?
> Given the conflation, I was then left confused by the GLEP requirement
> that the EAPI not be changed from that found in the filename (with the
> filename EAPI defaulting to 0 if not given), set against the argument
> that EAPI could then at some point be made dynamic, or otherwise less
> firmly specified than filename semantics requires.
But this would have to be based on /some/ sort of eapi suffix in the
filename, or the file would be sourced by current (not future) versions of
portage (the reason for changing the suffix in the first place.) Given that
why not just use the same in the ebuild EAPI="foo" declaration, with the
proviso that it's restricted to only appearing once in the file?
Still seems much cleaner to me. <sarcasm;> Oh yeah, we have to do this *now*
we can't wait 6 months or so, because there are tons of apps that our users
need, which they can't get without ebuilds using an api which can't be
sourced.</sarcasm>
This is supposed to be about the longer-term, not rushing through changes:
it won't exactly take long to get a version of portage that doesn't
automatically source ebuild files: it can just take the first EAPI line it
finds and not source anything it doesn't know about. As ever the maintainer
takes ultimate responsibility for ensuring their ebuild works, and the QA
tool can trivially confirm that there's only one EAPI declaration.
eg, this finds all ebuilds which have more than one SLOT declaration:
find /usr/portage -type f -name '*.ebuild' -exec bash -c 'for f; do
c=$(grep -c "\bSLOT=" "$f"); ((c>1)) && grep -H SLOT "$f"; done' _ {} +
[all one line]
It's not foolproof (gives false positives eg comments) so I'd use that other
regex for EAPI and put some faith in the maintainers (and the
commit-reviews.)
Oh yeah I forgot, McCreesh thinks they're all idiots[1], so let's just do
what he says. Funny thing is I think the USE-flag metadata thing would have
breezed through as a GLEP; I don't recall one person saying they thought it
was a bad idea.
[1]
http://lab.obsethryl.eu/content/paludis-gentoo-and-ciaran-mccreesh-uncensored
--
[EMAIL PROTECTED] mailing list
