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
