Hi!
On Sat, 16 May 2009, Ciaran McCreesh wrote:
> On Sat, 16 May 2009 18:31:38 +0200
> Tobias Klausmann <klaus...@gentoo.org> wrote:
> > On Sat, 16 May 2009, Ciaran McCreesh wrote:
> > > > So we're not talking about .ebuild-2 for EAPI=2, .ebuild-3 for
> > > > EAPI=3 etc? That would just be silly and it was the first idea I
> > > > got when I saw the proposal.
> > >
> > > Yes, yes we are. That's just one change, from a static string to a
> > > pattern for a string.
> > >
> > > Heck, pretend GLEP 55 says .eapi-X.eb instead if it makes you happy.
> >
> > It doesn't. I forsee a non-trivial amount of extra work, breakage
> > and pain with a moving extension. And not anywhere near enough
> > benefit in exchange for it.
>
> Why? What's the big deal with .ebuild-? or .eapi-?.eb instead
> of .ebuild?
One that you illustrate yourself: what aboud .eapi-11.eb or
.ebuild-11? What if you want to be able to choos EAPI names more
freely?
> > I think wanting incremental updates for version specs is a dream
> > we should abandon.
>
> It's an easy goal that we can deliver without much work. Ignoring it,
> on the other hand, means holding Gentoo back unnecessarily every time
> we want to change something.
And on the "without much work" we disagree wildly. I think it
creates more trouble than it's worth. Being an opinion, it's up
for change, naturally.
> > My point is this: from experience I suspect having a hard change
> > once and having easy progress on either side of it is preferable
> > to having mid-range complications all the time.
>
> .ebuild-? is not complicated.
Oh, it adds a variable portion to something that's otherwise
static.
glob regex
classic *.ebuild .*\.ebuild
\.ebuild$
pms-style *.ebuild-* .*\.ebuild-[0-9]+
\.ebuild-[0-9]+$
The newer sort of extension is much more involved to get *really*
right in patterns. Globs and regexen are only the two most
popular examples.
On top of that, other domains that are involved with ebuilds will
be more complex (and complicated) by a variable file extension.
And it's not just the command line for users. All code that
handles these files (yet probably doesn't even care about their
contents) needs to become more complex.
For all those who think they are regex wizzes: create a regex
that can tell properly formatted email-addresses from improper
ones. From scratch; heeding all RFCs. And no googling!
> > > Well, I strongly doubt that anyone's already thought of all the
> > > useful changes we might want to make in the future, so I don't
> > > think proposing a solution that assumes that they have is a good
> > > idea.
> >
> > I think it's a river we should think about once we reach it.
>
> Why? We know we'll reach it. Pretending we won't just means when we do
> reach it, we'll still be crossing it on foot rather than in a
> helicopter.
Every metaphor only goes so far, so I'll abandon it for now. When
we reach a point where we will need another change, we can make
an informed decision. Now, we can only guess what might need
change. As such, it's very difficult to create a system of easy
updates that cover all possibilities.
> > > Otherwise, in another year or two we'll just be back to "well we
> > > need to change extensions again, but let's just do it as a second
> > > one-off thing".
> >
> > My experience tells me that with proper preparation of *this*
> > change, that can be pushed past the "in the next ten years" mark.
> > And that is close enough to "indefinitely" for me.
>
> The only way it'll be "in the next ten years" rather than "in the next
> two years" is if Gentoo continues its current approach of making
> changes require every single person to agree...
There is such a things as too much change too quickly. And even
if we take that 2 years number: do *you* know what changes we
might need in two years? I suspect not. Neither do I (or just
about anybody else). I just think the hoops we have to jump
through now to tackle hypothetical problems in two (or ten) years
aren't worth it.
--
Found on a small utility knife in MIT's lab supply:
"Caution. Blade is sharp. Keep out of children."
