1 |
On Sat, 2007-07-21 at 11:48 -0700, Josh Saddler wrote: |
2 |
> (GDP): you give us the info, we'll document it for you. Or I will at least. |
3 |
|
4 |
Well, the changes are as outlined in my first email. |
5 |
The user changes are mainly a few variables in the /etc/conf.d/* files |
6 |
that baselayout ships. For example a few have been removed and a few |
7 |
have been added, and a few have changed. |
8 |
|
9 |
>From our perspective, /etc/conf.d/* is quite well documented, so GDP |
10 |
could easily diff the files to see what has changed. |
11 |
|
12 |
> Of equal concern to me, however are a few issues: |
13 |
> |
14 |
> 1) How will stabilization work? Is it a forced upgrade from stable 1.x |
15 |
> to 2.x, or can it be slotted? |
16 |
|
17 |
It cannot be slotted in any way or form. |
18 |
Also, the daemon state data is non transferable as the format has |
19 |
changed in baselayout-2. This is the data that records how a daemon was |
20 |
started by s-s-d so we can check if it's running or not. However, most |
21 |
end users won't be concerned by this. |
22 |
|
23 |
I've tested the ebuilds for upgrading and downgrading quite extensively, |
24 |
with the following notes. |
25 |
baselayout-1 *requires* bash. As such /bin/sh should point to bash |
26 |
before downgrading. |
27 |
If the /etc/init.d files are not immediately updated by etc-update or |
28 |
other means then errors will happen. What errors and how severe entirely |
29 |
depend on the scripts the user has in /etc/init.d |
30 |
|
31 |
> 2) It will be completely unmanageable to have more than one set of |
32 |
> baselayout instructions in the handbook & other docs, so there |
33 |
> definitely is a need for the migration doc. |
34 |
|
35 |
That's your call. |
36 |
|
37 |
> 3) How long will 1.x be kept stable? (This affects how long the old |
38 |
> instructions are in the handbooks etc.) |
39 |
|
40 |
Good question. We normally keep at least one major revision prior to the |
41 |
current stable in the tree. They can stay in the tree indefinitely I |
42 |
suppose, but the GDP should only follow the current stable. Maybe |
43 |
archive the handbook? |
44 |
|
45 |
> 4) What baselayout will be used in the next release? (Maybe that's more |
46 |
> of a releng question.) |
47 |
|
48 |
baselayout team just makes baselayout releases. If you mean the LiveCD |
49 |
then ask releng. |
50 |
|
51 |
> 5) Do you have a rough estimate (month, 3 weeks, 5 weeks, what?) on when |
52 |
> the first arches might be stabilizing 2.x? |
53 |
|
54 |
No. |
55 |
If the RC's prove stable and no serious regressions are reported for a |
56 |
month then we'll probably release a final 2.0.0 and get arch teams to |
57 |
mark stable a week later, or right away if no last minute changes have |
58 |
been made. |
59 |
|
60 |
> This is all from the GDP's perspective, almost none of it is of interest |
61 |
> to me as a user; I expect this sh** to work just as well as |
62 |
> baselayout-1.x when I hit the upgrade myself. :) |
63 |
|
64 |
In theory it should just work. Especially as Gentoo/FreeBSD has been |
65 |
running it as our standard baselayout for around 6 months now. So |
66 |
hopefully this should be a very smooth release. |
67 |
|
68 |
> Documenting this will be a major arsepain--er, effort--since baselayout |
69 |
> 1.x directions are already mixed in so well with pretty much every doc |
70 |
> we have. I'm not at all looking forward to fixing the docs when the time |
71 |
> comes, but I will do it provided I get to borrow your brain for a good |
72 |
> long time. :) |
73 |
|
74 |
Most of the documentation should still apply. I've tried to be as |
75 |
compatible as possible - the one possible exception being networking as |
76 |
baselayout-1 used bash arrays extensively. But we still support that |
77 |
if /bin/sh is bash, which it is by default for Gentoo/Linux |
78 |
|
79 |
Thanks |
80 |
|
81 |
Roy |
82 |
|
83 |
-- |
84 |
gentoo-dev@g.o mailing list |