Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote: > On Tue, 24 Feb 2009 12:25:27 -0500 > Jim Ramsay <l...@gentoo.org> wrote: > > > ...and it means we can't change name or version rules. > > > > > > ...and it means over doubling the best possible time to work out a > > > dependency tree in the common case where the metadata cache is > > > valid. > > > > > > ...and it means we can't make arbitrary format changes. > > > > Those would all land in the category of "backwards compatibility" > > mentioned below, as they would all break current sourcing rules. > > No, they're also future issues. Without glep 55, every time they come > up we have to go through the whole mess again.
This minor/major EAPI scheme is exactly equivalent to glep 55 in the ways that it addresses the non-implementation-specific details - It could even be added as a caveat to glep-55 that says something like: "You should not change filename extension (ie, major-EAPI version, or EPARSE version, or whatever we want to call it...) except when you *have to* because of changes such as name or version rules, arbitrary format changes, or anything else that breaks the sourcing rules of the existing filename extensions. Simpler feature improvements can be done using whatever internal minor-EAPI version is defined by the major-EAPI version." This doesn't prevent you from changing the filename extension when you have to do so, it just suggests that maybe you don't have to do it for every single feature-set you may want to implement. > > > Developers already have to stop and think and consult the > > > conveniently available table of features for EAPIs. By splitting > > > the EAPI concept in two you're doubling the amount of data to be > > > learnt. > > > > I would think that this is a very small cost, and the benefit would > > be (I hope) that more people would agree on the solution and then > > we can go forward. Is that not a valid consideration? > > I'd expect to see changes that would warrant a major bump in every > other EAPI or so anyway, so it's not really worth the complexity. If that is indeed the case, then adding this caveat to glep-55 is basically a nop. If every EAPI includes a non-backwards-compatible change that breaks existing PMs, the filename extension will be changed every time. But when you say "worth the complexity", I'm not exactly sure what your standards of "worthiness" are. I don't think the human cognition of a 2-level versioning scheme is that tricky, so I assume you must mean complexity in the internals of package managers - but this should just be a Simple Matter Of Programming. I'll further qualify this response by mentioning that I am not a package manager maintainer. I don't know beans about metadata and cacheing and what the tradeoffs may be between a two-level EAPI and a single-level EAPI stored in the filename. I understand that parsing two-level EAPI is "more expensive" than a single-level stored in the filename. I don't however know how to figure out if it is "too expensive", or whose subjective scale we should use to measure this. I personally feel the "complexity" that you say is too costly is a fair tradeoff for a proposal that people will accept. (Of course I have no idea if people actually would accept a two-level EAPI any more than glep-55 as-is... I just think it addresses the concerns I've heard in this thread in a way that does not break the valid solutions to real problems presented in glep-55) -- Jim Ramsay Gentoo Developer (rox/fluxbox/gkrellm/vim)
signature.asc
Description: PGP signature
