1 |
Hi! |
2 |
|
3 |
On Sat, 16 May 2009, Ciaran McCreesh wrote: |
4 |
|
5 |
> On Sat, 16 May 2009 18:31:38 +0200 |
6 |
> Tobias Klausmann <klausman@g.o> wrote: |
7 |
> > On Sat, 16 May 2009, Ciaran McCreesh wrote: |
8 |
> > > > So we're not talking about .ebuild-2 for EAPI=2, .ebuild-3 for |
9 |
> > > > EAPI=3 etc? That would just be silly and it was the first idea I |
10 |
> > > > got when I saw the proposal. |
11 |
> > > |
12 |
> > > Yes, yes we are. That's just one change, from a static string to a |
13 |
> > > pattern for a string. |
14 |
> > > |
15 |
> > > Heck, pretend GLEP 55 says .eapi-X.eb instead if it makes you happy. |
16 |
> > |
17 |
> > It doesn't. I forsee a non-trivial amount of extra work, breakage |
18 |
> > and pain with a moving extension. And not anywhere near enough |
19 |
> > benefit in exchange for it. |
20 |
> |
21 |
> Why? What's the big deal with .ebuild-? or .eapi-?.eb instead |
22 |
> of .ebuild? |
23 |
|
24 |
One that you illustrate yourself: what aboud .eapi-11.eb or |
25 |
.ebuild-11? What if you want to be able to choos EAPI names more |
26 |
freely? |
27 |
|
28 |
> > I think wanting incremental updates for version specs is a dream |
29 |
> > we should abandon. |
30 |
> |
31 |
> It's an easy goal that we can deliver without much work. Ignoring it, |
32 |
> on the other hand, means holding Gentoo back unnecessarily every time |
33 |
> we want to change something. |
34 |
|
35 |
And on the "without much work" we disagree wildly. I think it |
36 |
creates more trouble than it's worth. Being an opinion, it's up |
37 |
for change, naturally. |
38 |
|
39 |
> > My point is this: from experience I suspect having a hard change |
40 |
> > once and having easy progress on either side of it is preferable |
41 |
> > to having mid-range complications all the time. |
42 |
> |
43 |
> .ebuild-? is not complicated. |
44 |
|
45 |
Oh, it adds a variable portion to something that's otherwise |
46 |
static. |
47 |
glob regex |
48 |
classic *.ebuild .*\.ebuild |
49 |
\.ebuild$ |
50 |
|
51 |
pms-style *.ebuild-* .*\.ebuild-[0-9]+ |
52 |
\.ebuild-[0-9]+$ |
53 |
|
54 |
The newer sort of extension is much more involved to get *really* |
55 |
right in patterns. Globs and regexen are only the two most |
56 |
popular examples. |
57 |
|
58 |
On top of that, other domains that are involved with ebuilds will |
59 |
be more complex (and complicated) by a variable file extension. |
60 |
|
61 |
And it's not just the command line for users. All code that |
62 |
handles these files (yet probably doesn't even care about their |
63 |
contents) needs to become more complex. |
64 |
|
65 |
For all those who think they are regex wizzes: create a regex |
66 |
that can tell properly formatted email-addresses from improper |
67 |
ones. From scratch; heeding all RFCs. And no googling! |
68 |
|
69 |
> > > Well, I strongly doubt that anyone's already thought of all the |
70 |
> > > useful changes we might want to make in the future, so I don't |
71 |
> > > think proposing a solution that assumes that they have is a good |
72 |
> > > idea. |
73 |
> > |
74 |
> > I think it's a river we should think about once we reach it. |
75 |
> |
76 |
> Why? We know we'll reach it. Pretending we won't just means when we do |
77 |
> reach it, we'll still be crossing it on foot rather than in a |
78 |
> helicopter. |
79 |
|
80 |
Every metaphor only goes so far, so I'll abandon it for now. When |
81 |
we reach a point where we will need another change, we can make |
82 |
an informed decision. Now, we can only guess what might need |
83 |
change. As such, it's very difficult to create a system of easy |
84 |
updates that cover all possibilities. |
85 |
|
86 |
> > > Otherwise, in another year or two we'll just be back to "well we |
87 |
> > > need to change extensions again, but let's just do it as a second |
88 |
> > > one-off thing". |
89 |
> > |
90 |
> > My experience tells me that with proper preparation of *this* |
91 |
> > change, that can be pushed past the "in the next ten years" mark. |
92 |
> > And that is close enough to "indefinitely" for me. |
93 |
> |
94 |
> The only way it'll be "in the next ten years" rather than "in the next |
95 |
> two years" is if Gentoo continues its current approach of making |
96 |
> changes require every single person to agree... |
97 |
|
98 |
There is such a things as too much change too quickly. And even |
99 |
if we take that 2 years number: do *you* know what changes we |
100 |
might need in two years? I suspect not. Neither do I (or just |
101 |
about anybody else). I just think the hoops we have to jump |
102 |
through now to tackle hypothetical problems in two (or ten) years |
103 |
aren't worth it. |
104 |
|
105 |
|
106 |
|
107 |
|
108 |
-- |
109 |
Found on a small utility knife in MIT's lab supply: |
110 |
"Caution. Blade is sharp. Keep out of children." |