Ciaran McCreesh 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. > OK. Do you think a generated EAPI is a good idea? I'm curious as to how that would be reflected in the filename (as well as your reasons ofc.)
>> > 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. > No: without knowing the EAPI when generating said data. If that needs to be known relatively soon in order to generate the rest, extract it early. You still only need to load the file from disk once, and you don't need to source to get that data, given one simple restriction (only declaring it once.) >> (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. > The *reason* for the change is about the implementation, and it is not necessary. I accept it would make metadata generation quicker, but the end-user can already use -metadata-transfer atm and never need to run that process. It would save many more cycles if more users did imo (optimising early here seems silly tbh, given that paludis now requires ruby.) Given that, as a user I see no benefit to my machines that would justify the maintenance headache which I know as a coder this will result in. Quite apart from all the changes to supporting tools and workflow, it's pushing an implementation-specific datum into a namespace where it's neither needed nor useful, apart from to the implementation. Someone working on an ebuild will be looking at its text, and an end-user doesn't care. Revision numbers are of note to all parties, by contrast. >> > 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. > OK, but restricting EAPI= across the board (in the way that others have already asked for) and enforcing it via repoman would mean EAPI could easily be extracted. >> > 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. > Hmm I think you should consider the example that this sub-thread is about, and whether an apology would be in order. Since only declaring it the once /seems/ ok with you, what on Earth is so hard about extracting it? I'm sure ruby has sufficient text processing capability if the C++ is a bit much for you; I remember there was that long-term bug in paludis not being able to deal with whitespace in config files, so clearly something's up with your text-processing. Hope that's finally fixed now. -- [EMAIL PROTECTED] mailing list
