1 |
On Thu, 2004-05-20 at 11:26 -0500, Joseph Booker wrote: |
2 |
> foser said: |
3 |
> > Relatively speaking. Sure there's always a few users using them, but is |
4 |
> it worth what it adds in complexity ? |
5 |
> |
6 |
> those who care to get the optional features, those interested in what the |
7 |
> package can do. ebuild hacking should be a last resort to fix something |
8 |
> that wouldn't compile or any such situtaution where there is an error, |
9 |
|
10 |
Something not compiling by default is a bug (unless you have insane |
11 |
CFLAGS), that has nothing todo with 'users' hacking on ebuilds (i'm a |
12 |
user too). |
13 |
|
14 |
> nothing normal users should have to do provided the ebuild is |
15 |
> well-written. if you just use what you think are sensable defaults rather |
16 |
> then local use flags, then you will get bug reports of the users |
17 |
> submitting patchs to enable/disable these features to make the package |
18 |
> 'better'. how much choice is that? the idea of using packages like |
19 |
> php-with-mysql will come up, things will get less maintainable, bugs for |
20 |
> people being forced to edit ebuilds and doing it wrong, or worse, the devs |
21 |
> could refuse to help them as they are using modified unoffical ebuilds |
22 |
|
23 |
Well, mysql is as global as it gets and rightfully so, so that example |
24 |
wasn't chosen too well. This is not about removing obvious USE flags or |
25 |
anything. |
26 |
|
27 |
The people who tend to ask for obscure features/local use flags usually |
28 |
know perfectly fine how to accomplish their goals. That is the point. |
29 |
Nobody uses it, except them and they can have it on a local level just |
30 |
the way they want it (and probably already have it like that at that |
31 |
point). |
32 |
|
33 |
Bugs in local scripts are not bugs that devs should be held responsible |
34 |
for (as in solving them), but we have a tremendous community who usually |
35 |
have most stuff ready before the upstream devs even announced the |
36 |
release (thats a curse & blessing at the same time). In one way that is |
37 |
a compliment to the ease of Gentoo (what I'm trying to hold onto here) |
38 |
and on the other hand an indication that there is a thriving community |
39 |
that can help with most issues. |
40 |
|
41 |
> > To start : it is not equivalent, binary packaging is a mess of it's own |
42 |
> and ebuilding is starting to go that same way. And it used to be |
43 |
> perfectly fine to say such things ('edit it to your needs') and people |
44 |
> accepted that, because it was (is?) a breeze to edit simple builds |
45 |
> script for example. But somewhere along the way we moved to holding |
46 |
> hands for even the most obscure of setups. |
47 |
> |
48 |
> perhaps the gentoo comunity is become less and less made up of developers |
49 |
> who know how ebuilds work and bash scripting, and is now more and more of |
50 |
> those who can't? |
51 |
|
52 |
I never wrote a bash script before I joined Gentoo. But you pick it up |
53 |
in no-time, well... used to. Nowadays I agree it isn't as simple |
54 |
anymore, but that's actually my point. Some evil voices still say I |
55 |
can't do shell scripting (*cough* ciaranm *cough* ;) They're probably |
56 |
right, doesn't that make a point for the easyness of Gentoo buildscripts |
57 |
in itself? |
58 |
|
59 |
Sure the userbase has changed, but that still is no reason to add |
60 |
obscure options. I'm not against USE flags or anything, I'm against the |
61 |
proliferation of forced dumbing down to a level where only devs in a |
62 |
particular area know how to handle stuff, because it's complex mess of |
63 |
distro specific scripts & options (like some well-known distros do). |
64 |
|
65 |
- foser |