1 |
mbutcher wrote: |
2 |
> Interesting suggestions, but to me your solution looks more complex than the |
3 |
> status quo. Now, instead of just merging the files by hand, I have to: |
4 |
|
5 |
The idea I wrote is more to trigger more thoughts in hope of a better |
6 |
system than a real solution. My goal was to reduce works for most |
7 |
people while keeping it the same for the group of people that actually |
8 |
customized those. |
9 |
|
10 |
I'm pretty sure that most people here at first don't like my idea |
11 |
because I posted to -dev and therefore most of you will have custom |
12 |
scripts. But, because you have such scripts you already have the work |
13 |
of doing the merge therefore you don't lose anything. |
14 |
|
15 |
And you're more knowledgeable than others who can't/don't know how to |
16 |
customize those scripts. But right now the one who pay are the one who |
17 |
don't know. Because they have to do the merge and they are the newbies. |
18 |
|
19 |
|
20 |
|
21 |
> 1) Manage another set of scripts in another place (/etc/user.d), which makes |
22 |
> troubleshooting harder. |
23 |
|
24 |
We could actually have it inside the same place (using sym links) |
25 |
|
26 |
> 2) Deal with another set of config files (If I'm reading your second |
27 |
> paragraph correctly), which might break if a new ebuild adds or removes |
28 |
> options that this config file must have. |
29 |
|
30 |
It's not another set of config files. It's actually the distro set + |
31 |
the one your customized. So most users will only have the custom sets. |
32 |
|
33 |
> 3) Worry that any time I update a package, one of the scripts that _was_ |
34 |
> playing nicely will now be broken without giving me so much as a warning. |
35 |
|
36 |
That's true today also, aren't you worry that each time you emerge X11 |
37 |
it won't work anymore, or that each time you emerge baselayout it may |
38 |
break some basic application or binutils etc.. I mean the scripts are |
39 |
calling those application but if the application is broke the script |
40 |
also gets broke. I don't see this as a valid arguments for this discussion. |
41 |
|
42 |
If you claim that the script may get broke more than the program, I |
43 |
would not agree with you because I believe they are tested as much as |
44 |
the program themselves. (You may think that the program gets more tested |
45 |
but it only get tested inside gentoo on the same hardware/config |
46 |
platform as the people who also test their scripts.) |
47 |
|
48 |
> If we used your proposal for '.modif' scripts, then updating a build might |
49 |
> never warn us of the changes that _did_ take place, and _should_ be handled |
50 |
> differently in the custom script. If we added the functionality to portage to |
51 |
> warn us when a config script changed, then... well, we'd be back to where we |
52 |
> started. |
53 |
|
54 |
In that system where we would use sym links, if you customize a script |
55 |
and follow instruction, it would let portage detect that the file is a |
56 |
symlink and not a file and silently replaced it. If the file is not a |
57 |
symlink then it would act as if it was protected. Here I'm only talking |
58 |
about scripts not config files. If a scripts is also a config, then I |
59 |
would have mark as a bug to split them into a script and a config. |
60 |
|
61 |
Ideally you want to be warn when you did customize it not when you |
62 |
didn't. Right now the problem is that you always get and I think the |
63 |
big issue is that most people that get warns won't even know / figure |
64 |
out what to do exactly from that step on. While the one who customized |
65 |
their script will just need a reminder to check it out. |
66 |
|
67 |
> Also, I'd challenge the claim that 85-90% of Gentoo users do not alter their |
68 |
> init scripts. That may be true for Red Hat or Mandrake (though users of those |
69 |
> do have to update /etc/sysconfig files instead, which isn't any better to me). |
70 |
|
71 |
Look, My claim was not a fact. I think that this distro as great |
72 |
potential for anyone that used other linux distro for 1-2 years and are |
73 |
tired of waiting for distro update in order to update or try things out. |
74 |
Right now because the distro is below 1.0 I believe that most people |
75 |
using it are developers but I also believe that as you guys continue to |
76 |
enhance that system it will attract a lot more users who won't be |
77 |
developers. You probably already have seen that with the slashdot |
78 |
announcement (which is when I became a gentoo apprentice). |
79 |
|
80 |
> To me, the attractive part about the way it works now is that it is simple |
81 |
> and straightforward. I feel like I am in control of things when I update a |
82 |
> package. It took me (and probably most people on this list) a minimal amount |
83 |
> of time to learn the scheme, and now I rue the days when I used to spend |
84 |
> hours debugging problems in Red Hat init scripts (only to have my fixes |
85 |
> overwritten the next time I upgraded with RPM). |
86 |
|
87 |
Not really related, but feeling in control and being in control are very |
88 |
different thing. While you are in control becausse you can see the |
89 |
changes and analyse them think about those that don't know bash or that |
90 |
don't know that those scripts even exists, they won't even know why the |
91 |
new features they installed is not working even after the rc-update |
92 |
command has been issued. They will be even less in control than you |
93 |
wanted them to be at first. I agree it then offer a great opportunity |
94 |
to learn but that's what we call the hard way. |
95 |
|
96 |
I think that scripts should be treated as program, because that's what I |
97 |
think they are. If you silentely update program then why not silentely |
98 |
update scripts as well. That is my original issue. For some people |
99 |
customizing program is as frequent as the scripts themselves, would you |
100 |
warn them about each program modified? I don't think so, because they |
101 |
probably know their stuff. Therefore I think the same should apply to |
102 |
scripts. |
103 |
|
104 |
> I understand that the current way might slow you down if you're running a lot |
105 |
> of services. But to me, that's a small price to pay for soundness of mind and |
106 |
> simple elegance. |
107 |
|
108 |
I'm really happy with the distro, and I'm just trying to find spot for |
109 |
more enhancements. I even had realy hard time figuring out that one :-) |
110 |
because the distro is already great. |
111 |
|
112 |
Yannick Koehler |