On Sun, 2004-01-18 at 18:42, Brad House wrote:
> yes that would work, but drobbins already expressed a concern with
> USE=livecd   Since we base our livecds off of a stage3 which would
> NOT have USE=livecd, we have to reemerge baselayout.  I don't believe
> catalyst is capable of reemerging the same package that already exists
> on the system without hacking it up some, so the easier way around would
> be to make everyone bump the baselayout -rN and resnap the portage tree
> and make it depend on that version of baselayout.  Just another
> step which the whole point to catalyst was to have everything in portage
> and easy to use so general users could create their own livecds with
> their own apps, etc.

Oh, and I never said you had to remerge baselayout - but come to think
of it, you are right, it will have to be done so.  But it will have to
be done so anyhow.

So I do propose that catalyst rather install livecd-functions.sh by
itself, as it will:
1) Not need a remerge
2) Keep livecd-functions.sh seperate, so future fixes will not need
   a baselayout bump, but just an catalyst one.

> It is a solution, just not the best at this point :/
> I still don't see the security concern though, but perhaps I'm
> thick headed.
> 
> > Ok, what about catalist install its own version of livecd-functions.sh
> > for the moment, with the ebuild only when USE=livecd.  We then change
> > the bit for sourcing livecd-functions.sh in /sbin/rc to:
> >
> > --
> > --- rc-scripts-1.4.3.12p2/sbin/rc       2003-12-25 19:25:24.000000000
> > -0500
> > +++ rc-scripts-1.4.3.12p5/sbin/rc       2004-01-16 23:10:40.880824792
> > -0500
> > @@ -6,6 +6,7 @@
> >
> >  trap ":" INT QUIT TSTP
> >  source /sbin/functions.sh
> > +[ -f /sbin/livecd-functions.sh ] && source /sbin/livecd-functions.sh
> >  umask 022
> >
> >  try() {
> > @@ -163,6 +164,11 @@
> > --
> >
> > Meaning any of the livecd changes will _only_ be available on a livecd,
> > which cuts the uneeded overhead, and settles Paul's concerns?  When
> > USE=livecd then propagated, catalyst can then stop installing its own
> > version ...
> >
> >
> > --
> > Martin Schlemmer
> > --
> >
> > Martin Schlemmer
> > Gentoo Linux Developer, Desktop/System Team Developer
> > Cape Town, South Africa
> >
> >
> >
-- 

Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa