1 |
On Thu, 2007-02-08 at 14:49 -0700, Daniel Robbins wrote: |
2 |
> On 2/8/07, Ned Ludd <solar@g.o> wrote: |
3 |
> > As somebody that's had to hand write many of those kinds of scripts. A |
4 |
> > single rcS is not very ideal. Our init scripts are in fact mostly usable |
5 |
> > by busybox. Granted there are a few special special cases, but then Roy |
6 |
> > is offering to update those for free. One of the larger problems really |
7 |
> > boils down to many packages provide default init.d scripts and these |
8 |
> > expect the existing baselayout only. That will be a bigger feat to deal |
9 |
> > with later on down the road. |
10 |
> |
11 |
> Developers will then need to test their init.d scripts to ensure that |
12 |
> they are compatible with busybox. This is asking a lot of work of |
13 |
> people just so you can use Gentoo's initscripts for something they are |
14 |
> not really ideal for. |
15 |
|
16 |
I don't think anybody can/would expect that. They don't test for |
17 |
hardened or uClibc now before stabilizing a pkg. What would be nice |
18 |
to see is if a maintainer is offered a posix compliant init.d script |
19 |
that they merge it or allow those to be merged for a pkg they maintain |
20 |
as long as it does not degrade functionality. |
21 |
|
22 |
> Any time a script is updated a new rev of a |
23 |
> package is required, and this does impact users and will cause |
24 |
> packages to be rebuilt when a user does "emerge -u". So I think this |
25 |
> should be weighed against the potential benefits of baselayout + |
26 |
> busybox. |
27 |
|
28 |
busybox is not Roys underlying goal as far as I understand. I think he |
29 |
simply mentioned it as an example of another group who wishes to unify |
30 |
efforts and have an interest in getting away from arrays where feasible. |
31 |
|
32 |
> If you are targetting something smaller than 32MB, then maybe busybox |
33 |
> is appropriate. But you are trying to go really small, then you |
34 |
> probably don't want all the extra junk in our initscripts. And if you |
35 |
> are _not_ trying to go really small, then put bash in your filesystem, |
36 |
> not busybox, and the initscripts will work. If bash isn't fast enough |
37 |
> from a boot time perspective, then the gentoo initscripts certainly |
38 |
> aren't going to be fast enough either. |
39 |
> |
40 |
> In other words: |
41 |
> |
42 |
> busybox + single rcS file = fastest and simplest, smallest, best for |
43 |
> very small filesystems, not as flexible |
44 |
> |
45 |
> bash + gentoo baselayout = most flexible, biggest, slower, best for |
46 |
> feature-rich systems |
47 |
> |
48 |
|
49 |
> busybox + gentoo baselayout = ? |
50 |
|
51 |
It's been done in the past by end users. Before there were only about 4 |
52 |
changes needed to make it work. That all changed when bash arrays were |
53 |
introduced. |
54 |
|
55 |
> I think that in 99 out of 100 cases, if you have room for baselayout, |
56 |
> then you probably have room for bash too. And in 99 out of 100 cases, |
57 |
> if you can deal with the load time of baselayout, then you can deal |
58 |
> with the overhead that might be incurred from having bash. |
59 |
> |
60 |
> I'm just pointing out that it's not an obviously good combination. In |
61 |
> the grand scheme of things, maybe it's not a great use of developer |
62 |
> resources. Or, maybe I'm wrong and it is a great idea. |
63 |
|
64 |
His time and resources. His "itch" |
65 |
|
66 |
> Personally I think that "baselayout + busybox" may be cool, but adding |
67 |
> an aftermarket sunroof to your car can be cool too. But that doesn't |
68 |
> mean it's worth the effort :) |
69 |
|
70 |
I don't think those who are not interested in this will be burden by |
71 |
any extra effort. Worst case is maybe getting a bug assigned to you |
72 |
which offers a posix replacement/update for the default init.d a pkg |
73 |
you maintain might provide. |
74 |
|
75 |
> Really, it's hard for me to imagine many scenarios where you really |
76 |
> need the flexibility of baselayout but can't squeeze in bash. And I |
77 |
> have a pretty good imagination. |
78 |
|
79 |
baselayout is only about a half of a meg these days and probably |
80 |
getting smaller/faster with the addition of the multicall rc/runscript |
81 |
work he has been doing. |
82 |
|
83 |
Adding bash also requires ncurses which in turn mostly requires having |
84 |
a c++ aware compiler or using the nocxx,minimal flags. Even with those |
85 |
flags enabled I'm seeing 3M going to ncurses+bash. So I can for sure |
86 |
see the benefits. |
87 |
|
88 |
Also for a moment lets stop and think. Some XYZ update breaks |
89 |
ncurses/bash. Supporting this gives us a nice alternative way to still |
90 |
boot our boxes for rescue using ash or another shell which might not |
91 |
have such big deps. |
92 |
|
93 |
|
94 |
-- |
95 |
Ned Ludd <solar@g.o> |
96 |
Gentoo Linux |
97 |
|
98 |
-- |
99 |
gentoo-dev@g.o mailing list |