In the past we used to wait to branch spin-kickstarts until almost the next
release. This was because it avoided having to do commits to two branches
(in most cases) and with very little work being done specifically for the
release past the next one.
For F17 we did the branch close to when the release branched. It was
anticipated that some F18 work would be going on before F17 was released.
There didn't appear to be many issues as a result of this change. People
seemed to remember to commit to both branches. Git makes this easier than
perhaps it would have been under CVS. We did have one case where a merge
of master back into F17 was done instead of cherry picking, but that wasn't
too hard to fix.
Given that background, what would people like to see happen for F18?
I am slightly in favor of branching now, but if most want to wait until
some F19 specific changes are needed, that would be OK with me.
This is an annoucement/description for what's going to change in comps for:
As you've noticed, the package selection screen has changed in anaconda -
there is a list of choices to install on the left pane, and a list of
options in the right pane. We want to describe these choices in comps. Here
The choices on the left side are called 'environments'. They are defined
in comps like so:
<description>GNOME is a desktop.</description>
Each environment has a grouplist that lists the groups that make up this
enviroment - these are the required groups that will be installed if you
select this environment. It also has a list of options for that environment,
which are also groups in comps. Note that these groups do not need to have
optional packages; there is no individual package selection in anaconda.
Whenever an environment is selected in anaconda in the left pane, the right
pane will be populated with:
- the list of options for that environment in comps
- any other user-visible groups in comps
The latter is for compatibility with add-on repoitoriess that exist now.
All the component groups of environments, and groups available as options,
will be able to be installed with kickstart and/or yum post-install via @<name>
syntax. Future work may be done in yum/kickstart to allow specifying
Patches are available for yum and anaconda for handling this; they should be
built in the near future.
What's left to change:
- Addition/modification of groups in comps for enviroments/options
- Addition of environment metadata in comps
- (Potentially) removal of obsolete groups
- (Potentially) changes of spin-kickstarts to refer to the new groups
An example of the comps additions, with a few environments defined, is
attached. These environments were based off of the live kickstarts.
Hi Spins SIG,
I'm doing a Fedora JBoss Spin as my GSOC project at the moment. Most of
my efforts so far have been in packaging stuff to put into the spin, and
only recently has there started to be enough stuff to really call it a
spin. I'm still waiting for a few packages to come through the review
process before I will submit the spin for review/wrangling(?).
If you want to have a look at what I've got so far, you can see the
kickstart at . Any comments or questions welcome, even flames: I've
got pretty fire retardant skin!
Once the spin is submitted for review, can stuff still be added to it,
or what's the process for that?
Gerard Ryan :: gerard(a)ryan.lt :: http://blog.grdryn.me :: @grdryn
GPG Fingerprint: AA11 A666 C98E B6D8 231C 11ED 6EDC 7E4A 62BC 4A15