Ciaran McCreesh wrote: > On Mon, 09 Jun 2008 20:15:56 -0600 > Joe Peterson <[EMAIL PROTECTED]> wrote: >> Yes, if everyone is perfect and remembers to do things perfectly >> right, there would never be issues in many things, but when you make >> something more complicated, there will be more errors. > > So we shouldn't ever change anything?
Of course I don't mean that. But humans and computers are each good at a complementary set of things. Computers handle obscure complexity easily; humans do not, so it's better to let computers make our lives easier rather than the reverse when designing systems. >> So why would not a one-time new extension (e.g. ".eb") do the trick, >> just like ".cc" works for C programs? Unless you are talking about >> needing to specify the EAPI in the file if the more advanced features >> are to be used, but I see nothing wrong with that requirement - it's >> not much different than specifying a slot, keywords, whatever. > > Because then we won't be able to change source compatibility again in > the future without introducing yet another new extension. But GLEP 55 is suggesting exactly that: yet another extension for each new EAPI (I know it is defines this as ".ebuild-<EAPI>", but that is just semantics). Source compatibility is not an issue once the EAPI syntax in the file is defined and the package manager starts to recognize it. At that point it can handle the ebuild at whatever EAPI the ebuild declares. It is only the older unaware version of the package manager that would get confused, but that would be solved by a one-time extension change: the old one would not even look for the new (e.g.) ".eb" extension (only the old ".ebuild" one), which is exactly what GLEP 55 tries to address. But the extension change is only needed once. Once the EAPI syntax is introduced and the package manager has code to read it, the package manager is able to determine the EAPI for all future EAPIs. If some new syntax in an as-yet unsupported EAPI exists, the EAPI-version-aware package manager will not trip on it, since it can just not bother to deal with "future" EAPI ebuilds. Now, even if there is no extension change, if we wait long enough, the chances of an old machine stubbornly staying at an old (pre-EAPI-aware) portage version gets slimmer and slimmer. So I'm not even sure this one-time extension change is really mandatory. But if it is determined to be so, I still don't see why we need endless extension changes as suggested in GLEP 55. > Because the package manager doesn't know how to extract the EAPI from > ebuilds whose EAPI it doesn't support. For example, an EAPI 2 ebuild > might look like this: > > require mypackage using ANIMAL="monkey" > > How do current package managers understand that the EAPI there is 2? The old (non-aware) package manager version would not, and yes, it would fail. So there are two alternatives: wait long enough or do a one-time extension change. In the latter case, the package manager would not even see the new files. But the new package manager versions would determine the EAPI from a defined syntax and ignore ebuilds with "future" EAPIs. And I do understand the issue of sourcing, since ebuilds are bash. If sourcing is an issue (and I'm not sure it is an overriding one - that's a good discussion), I would suggest an out-of-band EAPI specifier, but not in the filename. Put it in a comment line in the header, like: # Copyright 1999-2008 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: /var/cvsroot/gentoo-x86/sys-fs/btrfs-...$ # EAPI=2 inherit eutils ... So, the first non-blank and non-'#' line (in this case, "inherit ...") would signify the end of the search for the EAPI= string, making parsing trivial. Therefore, the only rule would have to be that "EAPI=" needs to be in a header comment. Other rules could be that it needs to be the only thing on such a header line - whatever. Again, these are technical details, and I think we can all put our heads together to come up with the best way to do it. If sourcing is a better way to go (i.e. to allow EAPI= to be anywhere in the file with no comment char), caching it might be the answer. How to make this efficient would become an implementation detail. >>>> But what users *really* don't care about is EAPIs, and this GLEP >>>> would expose that technical detail to them in a very blatent way. >>> Anyone who cares about ebuilds at a file level has to care about >>> EAPIs. >> Not really. A typical user does not need to know about EAPIs at all, >> but he might want to peruse the portage tree to look for ebuilds. He >> might also want to grep for KEYWORDS or whatever. The user can delve >> into it as much as needed or desired, but if there are these >> mysterious EAPI numbers tacked onto the extensions, then it's an >> added complication that is not important to all users. > > The typical user should be using a tool to query that sort of thing. Sure, but my point is: some users *will* want to explore - why not encourage this? And if so, why not make the conventions used as clean and understandable (and elegant) as possible without added noise from details that do not belong at that (e.g. the filename) level? Gentoo is a technical distro, and we encourage users to get technical in every other way. Saying that they should remain at the portage interface level is not consistent with that philosophy. >> I assume you mean that EAPI needs to be in the file - again, is this >> bad? Many file formats specify a file format version as part of the >> file. > > It's a pain in the ass, because it means no introducing new global > scope functions and no changing behaviour of existing global scope > functions. > > Most file formats don't have to deal with the compatibility issues that > we do. For example, try feeding this C++ program to a C++0x compiler... Right: there are two things to consider: 1) do we want EAPI= to be in the global bash scope or out of band?, and 2) what happens when the syntax has errors? #1 needs more discussion, and #2, yes, should throw an error if invalid, but this also will be caught when the dev tests his/her ebuild (and/or by repoman), just as it is today, so I don't see a problem there. If it is an EAPI mismatch that would cause the syntax error, the updated package manager versions would handle it. -Joe -- gentoo-dev@lists.gentoo.org mailing list