On Sat, 22 Dec 2007 00:59:53 +0000 Steve Long <[EMAIL PROTECTED]> wrote: > >> Wow that doesn't half sound like nonsense. > > > > Unfortunately, it's not nonsense. It's entirely true. If you don't > > understand that then you can't contribute anything useful to the > > discussion, so kindly stay out of it. > > > [This (along with your stubborn refusal to ever explain anything) is > what I mean by your manner not inviting discussion.] > > The datum you want is in a line in the file, easily extractable > without sourcing. If you don't understand that it provides the same > functionality, kindly go back to Uni and ask them to take your degree > back.
Except there's absolutely no guarantee that it is, nor that it always will be. > >> An EAPI="blah" at top-level in the file is exactly the same as the > >> suffix in terms of what can be represented > > > > But not in what can be changed. > > > Nonsense: if the file isn't source'able the package manager will know > this due to the EAPI line giving an unknown key, and won't bother > doing anything else with it. > > You can put whatever you want in there as long as you have the EAPI > declaration. Which is what I said: it's different in what can be changed. > >> According to the original discussion this was always supposed to > >> be a variable set in the ebuild source: > > > > And things moved on. Right back when this first came up several > > people pointed out why a variable isn't an optimal solution. > > > You can't even be bothered to provide a link, let alone any sort of > explanation. You haven't explained at any point why a line in the > ebuild is so unacceptable, yet you keep asserting that it's already > been established that it won't work. Even though that was the design > that was originally agreed upon, back when you were still a Gentoo > dev. The GLEP explains it all. > >> At that time others made the case for restricting its format in > >> exactly the same way you have been resisting for the ebuild source, > >> but see as fine for tacking onto the end of the filename: > >> "I would also suggest requiring that EAPI can be retrieved by a > >> simple line by line parsing without using bash. (This allows for > >> changing the parsing system)"[2] > > > > Except that that proposal doesn't work, as we've already > > established. > > No you just state it, in other threads too. That's not establishing > anything, and certainly not consensus. > > It is trivial to extract one line and gives the information required > without sourcing. In effect, it's stating that the one thing which > can't be dynamic in an ebuild is the EAPI setting, which your > proposal requires as well. No, it's stating that EAPI has to be static, in a particular format, in a particular place, set in a particular way. Only the first of those is a reasonable requirement. > >> The idea of a different suffix was discussed back then as well: > >> "portage *should not* ignore those ebuilds. If the user > >> wants to merge something that is a later ebuild api then they have, > >> at least portage chucks an exception that the UI can wrap into > >> 'upgrade portage'. > > > > There are times when the ebuilds have to be ignored. > > > Yes and if the EAPI is unsupported the manager can skip it. Again, you miss the point: at the package manager, there's a distinction between knowing that there's an ebuild that isn't supported because of its EAPI and not even being sure what exactly a particular ebuild is to the extend that you don't know its CATEGORY/PN/PV. Only being able to handle the first of these is insufficient. > > It's so that the ebuild's EAPI can be extracted. The way things are > > currently, there is no way to get an ebuild's EAPI without already > > knowing its EAPI. > > > Like I said, it's trivial to extract a line from the ebuild without > sourcing. You know it is, and so does everyone else. Note *the way things are currently*. If you think this is untrue, provide an algorithm that will correctly give the EAPI of any current or future ebuild given that ebuild's filename (hint: you can't). > > And *again* you demonstrate that you don't understand the metadata > > process. The metadata cache cannot be generated without already > > knowing the ebuild's EAPI, which is part of its metadata. > > > So extract the line and get the value, and stop pretending this is > some mystic art only you and the people who agree with you have the > ability to comprehend. It's coding, and yeah it's tricky sometimes, > but it's being run by a CPU; if you can explain it to the computer > you can explain it to someone else (if you want to; if all you're > about is putdowns, ofc, you can obfuscate and take 5 mails to get > across what could have been done in 1, all the while telling the > people who have no choice but to deal with you that it's all their > problem. Asperger's is bad, m'kay?) With the way things are currently you *can't* extract the line and get the value, because there's no guarantee on what the line is or what the meaning of global scope statements are. For example, what's the EAPI for the following ebuild? # Copyright blah inherit vim-spell using language="en" > >> >> (optimising early here seems silly tbh, given that paludis now > >> >> requires ruby.) > >> > > >> > Eh? Now what're you on about? > >> > > >> http://bugs.gentoo.org/show_bug.cgi?id=198864 > > > > Thankyou for demonstrating to everyone that you don't know what a > > USE flag is. > > > Eh, no I had thought that the reason people have been complaining > about paludis bloat and forcing make -j0 (512MB of RAM required per > make process) was the dep on ruby. Clearly you can bloat it all on > your own. Amusingly enough... It's due to the (optional) dep upon Python, not Ruby. But hey, carry on not having a clue what you're on about. > > ...and imposes arbitrary, pointless restrictions upon the format, > > which is exactly what EAPI is supposed to prevent. > > > Rubbish: it imposes a restriction on ONE line of the whole thing. And > the restriction on the format of that item, is less than the > restrictions implicit in making it a file suffix. Nnnnope. The suffix approach doesn't prevent future changes that use new suffixes. > > No, there's a pre-pass layer which by its existence enforces > > restrictions. > > > You just said we were adding it with the "file format restrictions" > on one line of the ebuild; I simply pointed out that it doesn't have > to be checked by the package manager. That means the limited > restriction (which no-one minds) enforced by repoman is not "adding > in a pre-pass layer enforcing new file format restriction" as you > incorrectly stated. The package manager has to check its input, since repoman may not have been run, and it has to have the pre-pass layer to be able to generate EAPI to be able to generate metadata. So yes, it is entirely necessary with your proposal. -- Ciaran McCreesh
signature.asc
Description: PGP signature
