On 12/29/2009 12:23 AM, Peter Robinson wrote:
On Mon, Dec 28, 2009 at 11:08 PM, Bruno Wolff III
> On Mon, Dec 28, 2009 at 22:58:23 +0000,
> Peter Robinson <pbrobinson(a)gmail.com> wrote:
>> 1) The reason for the new fedora-mini*.ks files is to slim down the
>> build. The difference between that and using a standard desktop one is
>> about 150 meg on a live CD the last time I tested it and when the
>> Moblin livecd is currently 400 meg that's quite a difference. I've
>> been working to and planning to work further to get the changes merged
>> in upstream. There are a number of bugs filed already and in Jan when
>> I have some more time I'll be following it up with other stuff.
> Do you think it might be better to remove more stuff from live-base and
> add it back in to live-desktop where needed? And remove the need for
> a fedora-mini-base.ks? Or perhaps if the mini ks is still desireable,
> to base it over of live-base instead of starting from scratch. This would
> probably help with maintenance down the road.
I think its 6 to one, half a dozen to the other. I think the desire is
still there. By slimming the base and moving it out to the individual
desktop .ks files you could be adding duplication and complexity
unnecessarily there. I think in the short term from the rather big
investigation it will be easier to have a separate one.
As far as the desire of stripping down the bare minimums of what a
livecd contains goes, here's my take on the problem;
If fedora-live-base.ks would just be the bare minimum of packages and
settings and scripts to make a LiveCD as such work (along with it's
features), then there would be no need to strip anything off.
Should there be a set of packages that any desktop/foo/bar oriented spin
requires, well, then enter fedora-live-desktop.ks or fedora-live-foo.ks.
We should always remember though, that even though collaboration on
fedora-live-base.ks is a very beautiful thing, in the end it is about
The maintainers should have ultimate control over the contents of the
spin and so if fedora-live-base.ks puts stuff on there we don't need,
then maybe it has to go (even if that means 5 other spins need to add a
package to their list).
Should something be removed from a group however, it's up to us to
forward such to the people maintaining comps.xml (which is all of us).
Ultimately the work has to be done somewhere. Sometimes by trying to
merge it all together you just end up with more of a mess and creating
more issues and more work for more people than by having two separate
ones and comparing them on occasion. In the not too distant future I
suspect there will be more than just Netbooks. At the very least there
will be a sugar one as its covers a lot of the ground that Moblin
does. There's likely also to be a MID one and support for secondary
arch devices too. There's nothing to say it can't disappear in the
>> 2) The mesa-dri-drivers-experimental is needed for 3D on ATI based
>> cards otherwise the Moblin interace is unusable with those devices (15
>> seconds + to activate a menu) but with luck that should be obsolete
>> for F-13
> That's pretty much what we figured, but there should probably be a deadline
> where if the graphics supoort is ready, the official spin gets pushed to
> F14 instead of F13.
Well that would be a question for the X guys not a mere user
environment guy like me :-)
List references to the issue as your dependencies, so that people can
help you track it, and other people can make noise about it at meetings
where show-stoppers for various things are addressed (blocker bugs, etc.).
>> other small devices such as scanners, perl, etc. I originally
>> with a fedora-desktop-base file and had about 4 or 5 pages of -blah so
>> I figured it was going to be easier and neater to start with nothing
>> and then add what I needed. I've had quite a bit of interest in it
>> from various areas.
> The issue with that approach is that if some change is made to add a
> feature to live-base it isn't going to get included in the mini ks.
> It might be safer to maintain a long subtraction list.
On the flip side of that argument its quite likely also that a feature
is added that we don't want and we then have to strip it out in other
.ks files adding more work possibly across multiple .ks files or
multiple levels of ks files. I'm not sure what the allergic reaction
to another -base.ks file is that I'm quite happy to maintain and get
rid of if necessary.
We would like to make sure that issues that make or break a LiveCD in
general are fixed in one location only. Maybe that means splitting up
fedora-live-base.ks, maybe there's another way.