On Mon, 09 Jun 2008 21:36:24 -0600 Joe Peterson <[EMAIL PROTECTED]> wrote: > 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.
And a file extension is far less obscurely complex than enforcing arbitrary syntax restrictions upon ebuilds. > >> 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). GLEP 55 suggests a backwards compatible, forwards compatible way of dealing with the problem that doesn't involve adding new sets of rules every few EAPIs. > 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. No it can't. EAPI has to be known before the source can start. Bash doesn't provide traps for executing code upon changed variables. > 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. No, it's only needed once per non-trivial change. So we might as well just change it for every EAPI. > 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. Which means we can't change anything useful in future EAPIs. Which, funnily enough, is what the GLEP is designed to solve. > 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. Except it is, because current EAPI aware package managers still can't deal with global scope changes. > > 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 then how do we deal with EAPI 3, where the syntax changes again? > 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 Which is way more obscure, complex and arbitrary than a file extension change. And it still imposes massive restrictions upon future EAPIs. > 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. Every issue you've raised so far was already discussed and debunked the first time this discussion happened. Please read the original discussions before continuing. > > 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? And when they do explore, they learn straight away what EAPI is. > 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. And users who get technical knowing what EAPI is is a good thing. > 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 We had that discussion when the GLEP was first proposed. -- Ciaran McCreesh
signature.asc
Description: PGP signature
