Ciaran McCreesh wrote: > On Thu, 20 Dec 2007 12:48:31 +0000 > Steve Long <[EMAIL PROTECTED]> wrote: >> >> 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.) >> > >> > You can't get the EAPI from the ebuild without knowing what EAPI the >> > ebuild uses. That's one of the points you're missing. >> > >> 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. >> 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. >> 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. >> 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. >> 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. >> With what you're proposing, we instead get bugs about portage missing >> packages."[3] > > Only when absolutely necessary -- and it's only absolutely necessary > when introducing changes such as version suffix extensions that would > result in packages not being usable anyway. > Yeah kinda like the idea of having an EAPI setting in the ebuild so that the manager can ignore it if it uses unsupported extensions, or even a different language. >> > It's an ebuild issue, not a package manager issue. >> > >> You keep saying that; sure EAPI is visible to ebuild and maintainer >> (doh) but the reason you have stated for this change in file naming >> (which is a lot more far-reaching than a simple restriction on the >> format of a variable) is so that the *PM* doesn't have to source the >> ebuild to get the EAPI. > > 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. >> > You're confusing the two different types of metadata. Which again >> > shows that you need to start understanding the metadata process >> > before trying to discuss design decisions relating to it... >> > >> It doesn't make any practical difference[4]: the computational issue >> is how to avoid a source statement via bash from another language. >> >> I note in passing that a metadata cache is available, with no runtime >> requirement on the user's part, since it is taken from the rsync'ed >> data. > > 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?) >> >> (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. >> >> > 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. >> > >> > Except that it's an arbitrary, pointless restriction. >> > >> Er arbitrary, no, since in practise it means exactly the same thing >> as the filename suffix (one single string declaration.) Pointless not >> at all, since it allows you to avoid calling bash and waiting for it >> to source, without an ugly hack. It also keeps the existing work >> practises that everyone is used to and doesn't mandate any changes to >> support tools. > > ...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. >> >> Since only declaring it the once /seems/ ok with you, what on Earth >> >> is so hard about extracting it? >> > >> > With the current situation, the EAPI has to be known for the EAPI >> > to be calculated. Adding in a pre-pass layer enforcing new file >> > format restrictions does not solve the problem we're trying to >> > address. >> > >> There is no pre-pass layer enforcing restrictions (nice FUD though); > > 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. Honestly it's hard to keep with what you think you're talking about; one minute things have to be very restricted, the next we have to support use cases no-one is interested in. You wade into a sub-thread and apparently forget the code example under discussion, even though it's in the prior mail, yet insist that everyone else *research* your words; and not only across threads, no we apparently have to read through your code as well as your frankly unpleasant words, simply to get an idea of what problem you think this is solving. Not conducive to Free software development, not what the Gentoo community is about (or at least, not the one I enjoy) and certainly not my idea of fun. -- [EMAIL PROTECTED] mailing list
