Thomas Pani wrote:
> My concern is technical: Filenames are for identifying files uniquely.
> An ebuild is uniquely identified by <cat>/<pn>-<pv>, so that's what it's
> filename should be. Adding anything else to the filename will only
> clutter the tree and lead to additional inconsitencies. Yes, you can
> check for these using QA tools. But if it's not in the filename you
> don't have to check.
> If you say that package managers need the EAPI info so early that they
> can't even read the first non-comment line of an ebuild that's fine. Go
> and place it in the filename. But nobody had a *technical* argument why
> that's the only possible solution so far. All I got was "you don't
> understand all that fancy PM stuff".
Good point. First of all, and this is an architecture/design issue, the only
valid reason to put the EAPI in the filename is that is *belongs* there in
principal. File extensions are for file types, not for info that really
should be in the file. If the motivation for placing the info in the filename
(and worse, the *extension*) is that of performance, you should think twice
about putting it there. If this is to address a technical problem, it should
be solved in a technical way. The format of a filename should be determined
by policy, not technical implementation or convenience.
Technical reasons to avoid the filename are:
1) Increase of [needless] complexity in filenames/extensions (and only one
example of the impact is that searching for ebuild files becomes less
straightforward).
2) Having the same info in more than one place is bad (requiring extra repoman
checks and the potential for ambiguity). I don't care how many people
say a) that this is not an issue or b) that it's "not a duplication",
in every data system I've worked on, it has been a very bad idea to have
more than one version of the same info that can get out of sync with each
other. Even if you take great care, I'd still always want to check both
and not trust either version of the info blindly. Caching or hashing is
different (i.e. where the caching mechanism is robust), since the
system itself keeps the cache up to date, and one version of the info
is stricty derived from the other rather than both being the source.
3) It uses the extension in a way that goes against common use in computers.
Other reasons:
1) Littering the filename with this kind of stuff is potentially confusing do
both devs and users - I know it's been stated that users don't care, but
I don't think that's a good assumption.
2) It does not appear to be an elegant filename policy (and this can be
considered technical as well), since elegance is something designed int
good systems.
3) Assuming going this route is a mistake, it could be hard to reverse.
I just don't want to see something like this happen as a quick fix without
exploring all of the implications and how it effects what I consider a very
good system (portage/ebuilds) currently. Also, it seems to me that there are
lots of other alternatives that have been discussed here (and some dismissed
rather quickly). Portage and its policy are very core to Gentoo, and care
should be taken on this.
-Joe
P.S. I just joined Gentoo this year, and it is disheartening to see the
nastiness that some people are resorting to on this list. I've never seen so
much anger and biting remarks in a project, and I can imagine it keeps some
from responding, which is ashame, since issues like this benefit from many
diverse viewpoints.
--
[EMAIL PROTECTED] mailing list
