Sorry for the lateness of my reply but I have been slow to catch up on
my email reading....
I definitely think that other spins could benefit from a more slimmed
down base.ks definition, specificity thincrust and ovirtnode which are
doing similar things to what Peter's fedora-mini*.ks sounds like.
On 12/28/2009 06:50 PM, Peter Robinson wrote:
>> 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.
Agreed, fedora-live-base.ks only included what is needed to produce a
bare minimal working livecd image.
>
> 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 spins.
>
> 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).
All of the above sounds reasonable. I have had it on my list for Jan
already to go through it all and see what can be merged, changed,
fixed etc (I think I mentioned this to you at FUDCon, but possibly
not) so with luck most of the issues might just go away. Unfortunately
December has been manic and it hasn't got high enough on the ToDo list
yet.
>> 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.).
I need to dig deeper on this one and do more testing and find out what
the plan is for it from a mainline desktop perspective.
>>>> other small devices such as scanners, perl, etc. I originally started
>>>> 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.
I do not know if there is another way, but I have always envisioned
having another layer below fedora-live-base. Weather its called
"fedora-min" whatever, but if fedora-live-base extended this it would 1)
not break existing spins, and 2)other smaller spins or spins that may
not even be livecd's can use this minimal ks as a starting point. This
was one of the initial ideas behind the AOS.
In upstream ovirt we take it even further and have snippets for
base-install.ks, base-pkgs.ks, and base-post.ks.
Introducing *all* of this extra abstraction may not be necessary,
however it would defiantly be nice to have a minimal package set
definition to produce a small foot print fedora image.
-D