Mailing List Archive: baselayout-2 stablisation plans

baselayout-2 stablisation plans

uberlord at gentoo

Jul 21, 2007, 7:36 AM

Post #1 of 38 (3058 views)

This is just a heads up for getting baselayout-2 stable. Next week I
plan to put baselayout-2.0.0_rc1 into the tree without any keywords and
it will be removed from package.mask (keeping the current alphas masked
though). Arch teams will then be pinged on a bug to keyword
baselayout-2.

Now there are, as usual, some daemons and init scripts that probably
won't work. For those that don't, I have either fixed or there's patches
in our bugzilla. Here's a rough summary.

Regarding init scripts.
Init scripts should now be strictly bourne or POSIX shell. ie, no
bashisms. bash init scripts will work, but ONLY if /bin/sh is bash.
Shells as /bin/sh that I've tested and found to be working are
bash
dash
busybox
zsh
FreeBSD sh

Also, as there's no bashisms, that also means no bash arrays. This
includes our net config.
config_eth0=( "1.2.3.4/24" "5.6.7.8 netmask 255.255.255.0" )
becomes
config_eth0="'1.2.3.4/24' '5.6.7.8 netmask 255.255.255.0'"
Pay attention to the quoting there.
We still support bash arrays if and only if /bin/sh is really bash, so
your existing net config should work as is.

Regarding start-stop-daemon. It will now test to see if the daemon is
running after it returns as some daemons love to fork and then error on
a bad config. So we trap this. However, there are also some false
positives where there is a big gap between forking and writing the
pidfile. Examples of this are ntpd (patch in portage) and nscd (part of
glibc).

Also, when running in parallel, we now prefix all output. This looks
very pretty on screen and is almost perfect. However, this also comes at
a cost - daemons are now expected to close stdin, stdout and stderr
after forking like all well written daemons should. Some don't - like
gpm (latest rev is patched) and noip (patch in bugs). If they don't,
then it will hang rc. Sadly, there isn't much I can do about this.

Lastly, reiserfs3 and jfs users should comment on bug #116016 to ensure
that my proposed patches to the userland tools actually work as I don't
use those fs's much aside from basic testing.

Well, that's about it. It's been a fun journey making baselayout-2 and
we're almost at the end of this road :)

Thanks

Roy

PS - Now is a very good time to test it if you're concerned about it
running on your obscure arch or use some funky networking foo.

--
gentoo-dev@gentoo.org mailing list

Re: baselayout-2 stablisation plans [ In reply to ]

Jul 21, 2007, 9:15 AM

Post #2 of 38 (3050 views)

Roy Marples wrote:
> This is just a heads up for getting baselayout-2 stable. Next week I
> plan to put baselayout-2.0.0_rc1 into the tree without any keywords and
> it will be removed from package.mask (keeping the current alphas masked
> though). Arch teams will then be pinged on a bug to keyword
> baselayout-2.

You should find someone from the GDP to write some user migration docs.
The two things that spring to mind are having to use init scripts for
device-mapper and crypto fs stuff (I can see lots of unbootable systems
for those who don't realise this...) and having to compile the new
splashutils *after* baselayout to keep fbsplash working.

Thanks for all your work on baselayout-2!

Daniel

--
gentoo-dev@gentoo.org mailing list

Re: baselayout-2 stablisation plans [ In reply to ]

uberlord at gentoo

Jul 21, 2007, 9:26 AM

Post #3 of 38 (3046 views)

On Sat, 2007-07-21 at 12:15 -0400, Daniel Drake wrote:
> Roy Marples wrote:
> > This is just a heads up for getting baselayout-2 stable. Next week I
> > plan to put baselayout-2.0.0_rc1 into the tree without any keywords and
> > it will be removed from package.mask (keeping the current alphas masked
> > though). Arch teams will then be pinged on a bug to keyword
> > baselayout-2.
>
> You should find someone from the GDP to write some user migration docs.

Good idea. Any volunteers?

> The two things that spring to mind are having to use init scripts for
> device-mapper and crypto fs stuff (I can see lots of unbootable systems
> for those who don't realise this...) and having to compile the new
> splashutils *after* baselayout to keep fbsplash working.

I don't actually know how to set those up or what the migration path
would be. Maybe devzero and strerror could document this as I understand
they do this.

Thanks

Roy

--
gentoo-dev@gentoo.org mailing list

Re: baselayout-2 stablisation plans [ In reply to ]

Jul 21, 2007, 9:45 AM

Post #4 of 38 (3059 views)

Roy Marples wrote:
> I don't actually know how to set those up or what the migration path
> would be. Maybe devzero and strerror could document this as I understand
> they do this.

I manage systems with a single RAID 0 stripe (not dmraid) managed by
device-mapper. When upgrading baselayout, we also have to upgrade to a
recent device-mapper version which provides the device-mapper init
script. Then we must run:

# rc-update add device-mapper boot

If we don't, we get an unbootable system.

Daniel

--
gentoo-dev@gentoo.org mailing list

Re: baselayout-2 stablisation plans [ In reply to ]

uberlord at gentoo

Jul 21, 2007, 10:17 AM

Post #5 of 38 (3046 views)

On Sat, 2007-07-21 at 12:45 -0400, Daniel Drake wrote:
> Roy Marples wrote:
> > I don't actually know how to set those up or what the migration path
> > would be. Maybe devzero and strerror could document this as I understand
> > they do this.
>
> I manage systems with a single RAID 0 stripe (not dmraid) managed by
> device-mapper. When upgrading baselayout, we also have to upgrade to a
> recent device-mapper version which provides the device-mapper init
> script. Then we must run:
>
> # rc-update add device-mapper boot
>
> If we don't, we get an unbootable system.

Probably a good idea to add that to the ebuild output too?

Roy

--
gentoo-dev@gentoo.org mailing list

Re: baselayout-2 stablisation plans [ In reply to ]

betelgeuse at gentoo

Jul 21, 2007, 10:19 AM

Post #6 of 38 (3049 views)

Roy Marples kirjoitti:
> On Sat, 2007-07-21 at 12:45 -0400, Daniel Drake wrote:
>> Roy Marples wrote:
>>> I don't actually know how to set those up or what the migration path
>>> would be. Maybe devzero and strerror could document this as I understand
>>> they do this.
>> I manage systems with a single RAID 0 stripe (not dmraid) managed by
>> device-mapper. When upgrading baselayout, we also have to upgrade to a
>> recent device-mapper version which provides the device-mapper init
>> script. Then we must run:
>>
>> # rc-update add device-mapper boot
>>
>> If we don't, we get an unbootable system.
>
> Probably a good idea to add that to the ebuild output too?
>
> Roy
>

Yes. That coupled with the ~arch Portage elog output at the end of
emerge will go a long a way to notifying users. If we would even have
news on that of that...

Regards,
Petteri

Re: baselayout-2 stablisation plans [ In reply to ]

calchan at gentoo

Jul 21, 2007, 10:56 AM

Post #7 of 38 (3049 views)

On 7/21/07, Roy Marples <uberlord@gentoo.org> wrote:
> Now there are, as usual, some daemons and init scripts that probably
> won't work. For those that don't, I have either fixed or there's patches
> in our bugzilla. Here's a rough summary.

About the nscd issue we discussed on irc on friday (i.e. daemon not
playing nice with parallel startup), your patch worked. It stayed on
my work laptop, though, so I can't file a bug right now. But I'll do
so monday morning.

Oh, and by the way, baselayout-2 is great stuff, thanks !

Denis.
--
gentoo-dev@gentoo.org mailing list

Re: baselayout-2 stablisation plans [ In reply to ]

nightmorph at gentoo

Jul 21, 2007, 11:48 AM

Post #8 of 38 (3048 views)

Roy Marples wrote:
> On Sat, 2007-07-21 at 12:15 -0400, Daniel Drake wrote:
>> Roy Marples wrote:
>>> This is just a heads up for getting baselayout-2 stable. Next week I
>>> plan to put baselayout-2.0.0_rc1 into the tree without any keywords and
>>> it will be removed from package.mask (keeping the current alphas masked
>>> though). Arch teams will then be pinged on a bug to keyword
>>> baselayout-2.
>> You should find someone from the GDP to write some user migration docs.
>
> Good idea. Any volunteers?

(GDP): you give us the info, we'll document it for you. Or I will at least.

Of equal concern to me, however are a few issues:

1) How will stabilization work? Is it a forced upgrade from stable 1.x
to 2.x, or can it be slotted?
2) It will be completely unmanageable to have more than one set of
baselayout instructions in the handbook & other docs, so there
definitely is a need for the migration doc.
3) How long will 1.x be kept stable? (This affects how long the old
instructions are in the handbooks etc.)
4) What baselayout will be used in the next release? (Maybe that's more
of a releng question.)
5) Do you have a rough estimate (month, 3 weeks, 5 weeks, what?) on when
the first arches might be stabilizing 2.x?

This is all from the GDP's perspective, almost none of it is of interest
to me as a user; I expect this sh** to work just as well as
baselayout-1.x when I hit the upgrade myself. :)

Documenting this will be a major arsepain--er, effort--since baselayout
1.x directions are already mixed in so well with pretty much every doc
we have. I'm not at all looking forward to fixing the docs when the time
comes, but I will do it provided I get to borrow your brain for a good
long time. :)

Re: baselayout-2 stablisation plans [ In reply to ]

uberlord at gentoo

Jul 21, 2007, 12:09 PM

Post #9 of 38 (3052 views)

On Sat, 2007-07-21 at 11:48 -0700, Josh Saddler wrote:
> (GDP): you give us the info, we'll document it for you. Or I will at least.

Well, the changes are as outlined in my first email.
The user changes are mainly a few variables in the /etc/conf.d/* files
that baselayout ships. For example a few have been removed and a few
have been added, and a few have changed.

>From our perspective, /etc/conf.d/* is quite well documented, so GDP
could easily diff the files to see what has changed.

> Of equal concern to me, however are a few issues:
>
> 1) How will stabilization work? Is it a forced upgrade from stable 1.x
> to 2.x, or can it be slotted?

It cannot be slotted in any way or form.
Also, the daemon state data is non transferable as the format has
changed in baselayout-2. This is the data that records how a daemon was
started by s-s-d so we can check if it's running or not. However, most
end users won't be concerned by this.

I've tested the ebuilds for upgrading and downgrading quite extensively,
with the following notes.
baselayout-1 *requires* bash. As such /bin/sh should point to bash
before downgrading.
If the /etc/init.d files are not immediately updated by etc-update or
other means then errors will happen. What errors and how severe entirely
depend on the scripts the user has in /etc/init.d

> 2) It will be completely unmanageable to have more than one set of
> baselayout instructions in the handbook & other docs, so there
> definitely is a need for the migration doc.

That's your call.

> 3) How long will 1.x be kept stable? (This affects how long the old
> instructions are in the handbooks etc.)

Good question. We normally keep at least one major revision prior to the
current stable in the tree. They can stay in the tree indefinitely I
suppose, but the GDP should only follow the current stable. Maybe
archive the handbook?

> 4) What baselayout will be used in the next release? (Maybe that's more
> of a releng question.)

baselayout team just makes baselayout releases. If you mean the LiveCD
then ask releng.

> 5) Do you have a rough estimate (month, 3 weeks, 5 weeks, what?) on when
> the first arches might be stabilizing 2.x?

No.
If the RC's prove stable and no serious regressions are reported for a
month then we'll probably release a final 2.0.0 and get arch teams to
mark stable a week later, or right away if no last minute changes have
been made.

> This is all from the GDP's perspective, almost none of it is of interest
> to me as a user; I expect this sh** to work just as well as
> baselayout-1.x when I hit the upgrade myself. :)

In theory it should just work. Especially as Gentoo/FreeBSD has been
running it as our standard baselayout for around 6 months now. So
hopefully this should be a very smooth release.

> Documenting this will be a major arsepain--er, effort--since baselayout
> 1.x directions are already mixed in so well with pretty much every doc
> we have. I'm not at all looking forward to fixing the docs when the time
> comes, but I will do it provided I get to borrow your brain for a good
> long time. :)

Most of the documentation should still apply. I've tried to be as
compatible as possible - the one possible exception being networking as
baselayout-1 used bash arrays extensively. But we still support that
if /bin/sh is bash, which it is by default for Gentoo/Linux

Thanks

Roy

--
gentoo-dev@gentoo.org mailing list

Re: baselayout-2 stablisation plans [ In reply to ]

vapier at gentoo

Jul 21, 2007, 12:28 PM

Post #10 of 38 (3045 views)

On Saturday 21 July 2007, Roy Marples wrote:
> On Sat, 2007-07-21 at 11:48 -0700, Josh Saddler wrote:
> >From our perspective, /etc/conf.d/* is quite well documented, so GDP
>
> could easily diff the files to see what has changed.
>
> > Of equal concern to me, however are a few issues:
> >
> > 1) How will stabilization work? Is it a forced upgrade from stable 1.x
> > to 2.x, or can it be slotted?
>
> It cannot be slotted in any way or form.
> Also, the daemon state data is non transferable as the format has
> changed in baselayout-2. This is the data that records how a daemon was
> started by s-s-d so we can check if it's running or not. However, most
> end users won't be concerned by this.
>
> I've tested the ebuilds for upgrading and downgrading quite extensively,
> with the following notes.
> baselayout-1 *requires* bash. As such /bin/sh should point to bash
> before downgrading.
> If the /etc/init.d files are not immediately updated by etc-update or
> other means then errors will happen. What errors and how severe entirely
> depend on the scripts the user has in /etc/init.d

i really think this bash vs POSIX issue is getting way more emphasis than it
should. i'd make the claim the majority of people out there dont even know
about /bin/sh, bash, dash, and friends, so most people out there will
have /bin/sh pointing to bash and as such, none of these things will be an
issue for them. anyone who has tried to switch /bin/sh to point to something
else has already seen their system blow up. or they're using baselayout-2
and so they're aware of the issues.

in other words, you want to put info in there about POSIX shell and changing
your conf.d files, great ... but dont emphasize it like it's doomsday and all
hell's gonna break loose when you upgrade.
-mike

Re: baselayout-2 stablisation plans [ In reply to ]

uberlord at gentoo

Jul 21, 2007, 12:39 PM

Post #11 of 38 (3051 views)

On Sat, 2007-07-21 at 15:28 -0400, Mike Frysinger wrote:
> i really think this bash vs POSIX issue is getting way more emphasis than it
> should. i'd make the claim the majority of people out there dont even know
> about /bin/sh, bash, dash, and friends, so most people out there will
> have /bin/sh pointing to bash and as such, none of these things will be an
> issue for them. anyone who has tried to switch /bin/sh to point to something
> else has already seen their system blow up. or they're using baselayout-2
> and so they're aware of the issues.
>
> in other words, you want to put info in there about POSIX shell and changing
> your conf.d files, great ... but dont emphasize it like it's doomsday and all
> hell's gonna break loose when you upgrade.

True enough, but now I've said it I'll sleep better tonight knowing that
I've at least warned some people who think wow - baselayout-2 supports
*faster* shells like busybox. I'll rock with my -fomg-optimized flags.
IE ricers who then bitch that their box is broke if they downgrade.

Thanks

Roy

--
gentoo-dev@gentoo.org mailing list

Re: baselayout-2 stablisation plans [ In reply to ]

klausman at schwarzvogel

Jul 21, 2007, 1:22 PM

Post #12 of 38 (3045 views)

Hi!

[... baselayout-2 is on the horizon ...]

Is there a common bug to report snags to? I've hit one:
/etc/init.d/net.eth0 used to be a symlink to net.lo. After
installing, it was gone (I figure it went with baselayout-1).
Luckily, I have direct console access, otherwise the machine
would have been gone after the reboot. Definitely something to
yell about during merging.

Regards,
Tobias

PS: If said bug exists, I'll gladly re-report there, but my
cursory search didn't turn up anything.
--
gentoo-dev@gentoo.org mailing list

Re: baselayout-2 stablisation plans [ In reply to ]

uberlord at gentoo

Jul 21, 2007, 1:28 PM

Post #13 of 38 (3047 views)

On Sat, 2007-07-21 at 22:22 +0200, Tobias Klausmann wrote:
> Is there a common bug to report snags to? I've hit one:
> /etc/init.d/net.eth0 used to be a symlink to net.lo. After
> installing, it was gone (I figure it went with baselayout-1).
> Luckily, I have direct console access, otherwise the machine
> would have been gone after the reboot. Definitely something to
> yell about during merging.

We don't ship with net.eth0 because there is no guarantee an interface
called eth0 exists. net.lo (net.lo0 in *BSDs) always exists so we just
ship that.

Thanks

Roy

--
gentoo-dev@gentoo.org mailing list

Re: baselayout-2 stablisation plans [ In reply to ]

uberlord at gentoo

Jul 21, 2007, 2:09 PM

Post #14 of 38 (3044 views)

On Sat, 2007-07-21 at 21:28 +0100, Roy Marples wrote:
> On Sat, 2007-07-21 at 22:22 +0200, Tobias Klausmann wrote:
> > Is there a common bug to report snags to? I've hit one:
> > /etc/init.d/net.eth0 used to be a symlink to net.lo. After
> > installing, it was gone (I figure it went with baselayout-1).
> > Luckily, I have direct console access, otherwise the machine
> > would have been gone after the reboot. Definitely something to
> > yell about during merging.
>
> We don't ship with net.eth0 because there is no guarantee an interface
> called eth0 exists. net.lo (net.lo0 in *BSDs) always exists so we just
> ship that.

One very good idea would be to get udev to create any net links that do
not exist to net.lo

Then we truly have plug and play :)

--
gentoo-dev@gentoo.org mailing list

Re: baselayout-2 stablisation plans [ In reply to ]

vapier at gentoo

Jul 21, 2007, 2:22 PM

Post #15 of 38 (3056 views)

On Saturday 21 July 2007, Roy Marples wrote:
> On Sat, 2007-07-21 at 21:28 +0100, Roy Marples wrote:
> > On Sat, 2007-07-21 at 22:22 +0200, Tobias Klausmann wrote:
> > > Is there a common bug to report snags to? I've hit one:
> > > /etc/init.d/net.eth0 used to be a symlink to net.lo. After
> > > installing, it was gone (I figure it went with baselayout-1).
> > > Luckily, I have direct console access, otherwise the machine
> > > would have been gone after the reboot. Definitely something to
> > > yell about during merging.
> >
> > We don't ship with net.eth0 because there is no guarantee an interface
> > called eth0 exists. net.lo (net.lo0 in *BSDs) always exists so we just
> > ship that.
>
> One very good idea would be to get udev to create any net links that do
> not exist to net.lo
>
> Then we truly have plug and play :)

indeed, that'd be sleeky and sexy ... go file a bug ;)
-mike

Re: baselayout-2 stablisation plans [ In reply to ]

Jul 21, 2007, 2:30 PM

Post #16 of 38 (3049 views)

Denis Dupeyron a Ã©crit :
> About the nscd issue we discussed on irc on friday (i.e. daemon not
> playing nice with parallel startup), your patch worked. It stayed on
> my work laptop, though, so I can't file a bug right now. But I'll do
> so monday morning.

I'll add mine about the dhcdbd patch you gave me 2 weeks ago. Works great.

> Oh, and by the way, baselayout-2 is great stuff, thanks !

+1 on that as well.

RÃ©mi
--
gentoo-dev@gentoo.org mailing list

Re: baselayout-2 stablisation plans [ In reply to ]

uberlord at gentoo

Jul 21, 2007, 3:02 PM

Post #17 of 38 (3043 views)

On Sat, 2007-07-21 at 17:22 -0400, Mike Frysinger wrote:
> indeed, that'd be sleeky and sexy ... go file a bug ;)

Let bug #186156 [1] be henceforth known as the sleeky and sexy bug!

[1] http://bugs.gentoo.org/show_bug.cgi?id=186156

Thanks

Roy

--
gentoo-dev@gentoo.org mailing list

Re: baselayout-2 stablisation plans [ In reply to ]

caster at gentoo

Jul 21, 2007, 3:18 PM

Post #18 of 38 (3043 views)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Roy Marples wrote:
> On Sat, 2007-07-21 at 17:22 -0400, Mike Frysinger wrote:
>> indeed, that'd be sleeky and sexy ... go file a bug ;)
>
> Let bug #186156 [1] be henceforth known as the sleeky and sexy bug!
>
> [1] http://bugs.gentoo.org/show_bug.cgi?id=186156
>
> Thanks

As you wish! [1] :)

[1] http://bugs.gentoo.org/show_activity.cgi?id=186156

- --
Vlastimil Babka (Caster)
Gentoo/Java
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGooZEtbrAj05h3oQRApS1AKCU0vyw+Oka3yPc4bByDHxPyQEDFwCgpzIL
F8ot8iOS1irR5UlcvDgpxFY=
=Ydgn
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list

Re: baselayout-2 stablisation plans [ In reply to ]

nightmorph at gentoo

Jul 21, 2007, 5:25 PM

Post #19 of 38 (3053 views)

Roy Marples wrote:
> On Sat, 2007-07-21 at 11:48 -0700, Josh Saddler wrote:
>> (GDP): you give us the info, we'll document it for you. Or I will at least.
>
> Well, the changes are as outlined in my first email.
> The user changes are mainly a few variables in the /etc/conf.d/* files
> that baselayout ships. For example a few have been removed and a few
> have been added, and a few have changed.

Yeah, I planned on doing some heavy reading of the new stuff, but I hope
I can get you all alone (heh heh heh) for awhile to go over questions
that will surely pop up. In case things like new networking configs
aren't intuitive, or whatever.

>> 3) How long will 1.x be kept stable? (This affects how long the old
>> instructions are in the handbooks etc.)
>
> Good question. We normally keep at least one major revision prior to the
> current stable in the tree. They can stay in the tree indefinitely I
> suppose, but the GDP should only follow the current stable. Maybe
> archive the handbook?

Archiving the handbook isn't possible. The only thing we archive for
historical purposes are the networkless handbooks, in
/doc/en/handbook/2006.0/, 2006.1/, etc. I'm thinking that if
baselayout-2 is the way of the future, then as soon as it's stabled for
all arches (see below for a bit more) then we should pretty much just
document that exclusively in all handbooks & docs. That's where a
migration guide will be so crucial. Since the thing can't be slotted,
and it's a forced upgrade (short of masking, but BAH to those users that
do it), I don't think we need to document two completely different
systems if they're both stable.

>> 5) Do you have a rough estimate (month, 3 weeks, 5 weeks, what?) on when
>> the first arches might be stabilizing 2.x?
>
> No.
> If the RC's prove stable and no serious regressions are reported for a
> month then we'll probably release a final 2.0.0 and get arch teams to
> mark stable a week later, or right away if no last minute changes have
> been made.

What'd really be nice is if it goes stable for all arches (or at least
all of the ones that matter, subjectively) either in time or after the
next release. Otherwise, there's going to be some more complications
from users who install from media containing old baselayout-1.x and have
to deal with the new 2.x right away. I guess we'll see. /me pokes
wolf31o2. ;)

> Most of the documentation should still apply. I've tried to be as
> compatible as possible - the one possible exception being networking as
> baselayout-1 used bash arrays extensively. But we still support that
> if /bin/sh is bash, which it is by default for Gentoo/Linux

Yeah. Though I still don't know the whole story, I anticipate that
updating the networking configs will be the biggest headache.

Re: baselayout-2 stablisation plans [ In reply to ]

uberlord at gentoo

Jul 21, 2007, 5:33 PM

Post #20 of 38 (3048 views)

On Sat, 2007-07-21 at 17:25 -0700, Josh Saddler wrote:
> Archiving the handbook isn't possible.

Why? Unless I'm missing something, it should be fairly trivial.

> What'd really be nice is if it goes stable for all arches (or at least
> all of the ones that matter, subjectively) either in time or after the
> next release.

That's kinda the plan. When the base system team was 4 people, we all
agreed that we just "make it stable" as it was mostly script based and
needed to be done at the same time.

I'd like to treat baselayout-2 the same, but as we're mostly C based
it's up to the arch teams to decide.

>
> > Most of the documentation should still apply. I've tried to be as
> > compatible as possible - the one possible exception being networking as
> > baselayout-1 used bash arrays extensively. But we still support that
> > if /bin/sh is bash, which it is by default for Gentoo/Linux
>
> Yeah. Though I still don't know the whole story, I anticipate that
> updating the networking configs will be the biggest headache.

Only for non bash /bin/sh - like FreeBSD.
But we don't have a handbook for that yet so it's no worry :)

Thanks

Roy

--
gentoo-dev@gentoo.org mailing list

Re: baselayout-2 stablisation plans [ In reply to ]

nightmorph at gentoo

Jul 21, 2007, 5:54 PM

Post #21 of 38 (3046 views)

Roy Marples wrote:
> On Sat, 2007-07-21 at 17:25 -0700, Josh Saddler wrote:
>> Archiving the handbook isn't possible.
>
> Why? Unless I'm missing something, it should be fairly trivial.

It ain't. It's an old issue.

Current networked (requires a net connection to install) handbooks go to
/doc/en/handbook/. Networkless (needs no net connection, only a liveCD
of some sort) goes to /doc/en/handbook/release_number/, like /2007.0/.
Whenever there's a new release, we can archive the networkless versions
because we just add a new dir for the latest version number. But
everything in /doc/en/handbook/ (networked) gets overwritten with the
stuff for the new release.

No way we can archive anything but the networkless handbooks. Besides,
that's mostly what you'd want anyway -- if you do the much more
up-to-date networked install, you're going to pull in all the new stuff
like baselayout-2 anyway, so you wouldn't want the old directions.

That's the theory, at least.

Re: baselayout-2 stablisation plans [ In reply to ]

agaffney at gentoo

Jul 21, 2007, 9:03 PM

Post #22 of 38 (3051 views)

Roy Marples wrote:
>> 4) What baselayout will be used in the next release? (Maybe that's more
>> of a releng question.)
>
> baselayout team just makes baselayout releases. If you mean the LiveCD
> then ask releng.

It'll be whatever version of baselayout is stable at the time we take the
initial release snapshot. However, if baselayout-2 will go stable a week after
we take the initial snapshot, it would probably be incorporated.

--
Andrew Gaffney http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer Catalyst/Installer + x86 release coordinator
--
gentoo-dev@gentoo.org mailing list

Re: baselayout-2 stablisation plans [ In reply to ]

cardoe at gentoo

Jul 22, 2007, 7:54 AM

Post #23 of 38 (3045 views)

Roy Marples wrote:
> On Sat, 2007-07-21 at 12:45 -0400, Daniel Drake wrote:
>> Roy Marples wrote:
>>> I don't actually know how to set those up or what the migration path
>>> would be. Maybe devzero and strerror could document this as I understand
>>> they do this.
>> I manage systems with a single RAID 0 stripe (not dmraid) managed by
>> device-mapper. When upgrading baselayout, we also have to upgrade to a
>> recent device-mapper version which provides the device-mapper init
>> script. Then we must run:
>>
>> # rc-update add device-mapper boot
>>
>> If we don't, we get an unbootable system.
>
> Probably a good idea to add that to the ebuild output too?
>
> Roy
>

I added that ages ago.

--
Doug Goldstein <cardoe@gentoo.org>
http://dev.gentoo.org/~cardoe/
--
gentoo-dev@gentoo.org mailing list

Re: baselayout-2 stablisation plans [ In reply to ]

m.debruijne at matrict

Jul 23, 2007, 11:31 AM

Post #24 of 38 (3057 views)

On Saturday 21 July 2007 16:36:03 Roy Marples wrote:
> This is just a heads up for getting baselayout-2 stable. Next week I
> plan to put baselayout-2.0.0_rc1 into the tree without any keywords and
> it will be removed from package.mask (keeping the current alphas masked
> though). Arch teams will then be pinged on a bug to keyword
> baselayout-2.
>
> Well, that's about it. It's been a fun journey making baselayout-2 and
> we're almost at the end of this road :)
>
> Thanks
>
> Roy

Hereby a friendly reminder that gcc-config should be keyworded as well,
current gcc-config isnâ€™t compatible with baselayout-2. According to Mike
gcc-config-1.4.0 is compatible with baselayout-2. (doesnâ€™t work on my system,
but I havenâ€™t investigated yet).
--
gentoo-dev@gentoo.org mailing list

Re: baselayout-2 stablisation plans [ In reply to ]

wolf31o2 at gentoo

Jul 23, 2007, 1:24 PM

Post #25 of 38 (3049 views)

On Sat, 2007-07-21 at 11:48 -0700, Josh Saddler wrote:
> 4) What baselayout will be used in the next release? (Maybe that's more
> of a releng question.)

Whichever is stable around September(ish) time frame will be what we
use, unless it is requested that we use something different.

--
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation