On Wed, 19 Dec 2007 11:05:35 +0000 Steve Long <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > On Wed, 19 Dec 2007 10:26:16 +0000 > > Steve Long <[EMAIL PROTECTED]> wrote: > >> Are you really telling me you are going to write _one_ ebuild > >> with /that/ god-awful hackery in it? > > > > Are you really suggesting that no-one ever will? > > > They won't if the spec and the docs say it's restricted to a single > instance, which can be checked trivially by repoman. The example > given was contrived and not at all representative imo; for instance > one could as easily do the same kind of thing with DESCRIPTION, but > it would be of little use and just add confusion to no purpose.
Except people *do* have generated DESCRIPTION etc, and with good
reason. A simple example is the vim-spell-* packages.
> >> Sticking to a single EAPI="xx" format in the ebuild means we don't
> >> have the *hack* of duplicating information in the filename (and the
> >> whole {pre,post}src issue, QA checks for human error since this is
> >> redundant info) simply to avoid parsing a config file.
> >
> > There is no duplication of information, nor redundancy.
> >
> So what were the QA checks you mentioned to confirm that the same
> EAPI is set in both the filename and the ebuild, for-- if not
> integrity of duplicated data?
It's to catch developers screwing up an unnecessarily specifying EAPI
manually. For example, someone might copy an EAPI 1 ebuild to
a .ebuild-2. But the only time that will happen is when there's a
screwup.
> > The pre/post source issue exists regardless of how EAPI is set --
> > it's just that with filename EAPIs, you aren't restricted to post
> > source changes.
>
> And what benefit does that provide, besides making it easier for your
> package manager?
It's not a question of ease. It's a question of being possible. You
need to understand the metadata generation process to understand why
the package manger has to assume a particular EAPI when generating the
metadata. Without the EAPI in the suffix, the assumed EAPI has to be
some weird combination of all existing and all possible future EAPIs --
which isn't logically sound.
> (I note this is a technical consideration of the implementation,
> given as a reason to change a clean API-- with consequences for
> workflow.)
No no. It's already an ebuild-visible issue, and there's no way it
can't be that doesn't involve imposing restrictions upon every single
possible future EAPI.
> > Ebuilds are not config files.
> >
> Indeed not, but they can be parsed as such for simple, core, metadata.
There is currently no information available from an ebuild that can be
parsed by any tool other than bash.
> > Really. It's a heck of a lot cleaner in the filename suffix.
> >
> Nah, it's an awful hack and you know it. It has nothing to do with
> package naming and is unnecessary exposure of internal data. -rN is
> ok, and there are rules on when and when not to bump rev; this is
> not. It's much cleaner specified as part of the ebuild in the same
> way as DESCRIPTION, so long as it is only specified once.
>
> Or do you see some real benefit to specifying EAPI more than once as
> in the example? If so, please share it.
And again, you show that you don't understand what's going on. EAPI is
only specified once except where developers screw up. The GLEP merely
moves the EAPI to being set *before* the metadata is generated, which
removes all the restrictions that having EAPI as part of the ebuild's
content imposes.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
