On Thu, 20 Dec 2007 12:48:31 +0000 Steve Long <[EMAIL PROTECTED]> wrote: > Point is that your filename format restricts it in exactly the same > manner. So let's just stick with the use cases which /that/ supports, > which can more easily be supported with the original design and the > simple restriction people keep asking for.
Er, the use case is having trivial-as-possible ebuilds for things that really are purely eclass managed. > >> 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. > 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. > 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. > 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. > 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. > 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. > (That was written when there were no other PMs besides > portage3/pkgcore) Learn your history. > > 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. > > 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. > >> (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. > >> >> > 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. > > > > 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. > >> Hmm I think you should consider the example that this sub-thread is > >> about, and whether an apology would be in order. > > > > Huh? > > > Gee is it really that hard to look back at the example from your > colleague that started this sub-thread? Yet you expect everyone else > to keep track of every delightful comment from you.. *sigh* The problem is, it's rather hard to keep track of what you think you're going on about when your arguments are based upon a very limited understanding of what's being discussed. > >> 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. > [4] But thanks for the explanation, that really cleared things up. > I'll assume you're talking about metadata generation during depgraph > resol'n then, until you scold me for misunderstanding again. And I > note that you have been disparaging of discussion of bash > optimisations in eclass/ebuild code, yet are falling over yourself to > give everyone else a load of work to speed up what I thought was > already the fastest PM known to humanity. Uh... It's not a performance issue. And again you show just how badly you fail to get what's being discussed. -- Ciaran McCreesh
signature.asc
Description: PGP signature
