4:48 p.m.
Hi All,
Firstly sorry for the cross post, I think its some what relevant for both.
I started this discussion in the F-13 timeframe but it was too late in
the cycle and was considered to risky, leading up to the beta it might
be a little close too.
Looking through the various kickstart files in the git repo while
looking at a couple of issues that I'm seeing on my own spins I have a
couple of queries.
Firstly in fedora-live-minimization.ks and fedora-livecd-desktop.ks
there's a whole lot of removal of packages. This is basically what i
do in the fedora-live-mini.ks and I think things like @printing can
(and should be) removed from base so that other kick starts don't have
to explicitly remove everything that it adds in. Its easy enough for
the people that want printing to add the one liner into their own
kickstart.
There's also a comment in the fedora-live-minimization.ks about
removing them from comps for F-14. Is there a reason this hasn't
happened? I was also suprised to see things like "printing" related
things in the base-x group in comps. It looks like someone had this on
their todo list, is it still there?
Ultimately I would like to get rid of the fedora-live-mini.ks file and
use the mainline base. I believe that base should be exactly that...
the base/core packages and all the useful scripting. Then possibly
have a base-desktop which adds all the core X stuff that any desktop
spin would need (plus associated related scripts that all could make
use of like X auto login). From there a desktop based spin would just
need to pull in the base-desktop.ks to get all the core stuff to get
to a minimal X.
Thoughts?
Peter
5 p.m.
On Tue, Aug 31, 2010 at 22:48:48 +0100,
"pbrobinson(a)gmail.com" <pbrobinson(a)gmail.com> wrote:
Firstly in fedora-live-minimization.ks and fedora-livecd-desktop.ks
there's a whole lot of removal of packages. This is basically what i
do in the fedora-live-mini.ks and I think things like @printing can
(and should be) removed from base so that other kick starts don't have
to explicitly remove everything that it adds in. Its easy enough for
the people that want printing to add the one liner into their own
kickstart.
I am not sure who owns the base (and core) definitons. Requesting a change
to make removing printing easier seems like a good idea.
I do have a question before we go that route though.
Would using -@printing work to drop the printing stuff before the deps
are brought in?
Ultimately I would like to get rid of the fedora-live-mini.ks file
and
use the mainline base. I believe that base should be exactly that...
the base/core packages and all the useful scripting. Then possibly
have a base-desktop which adds all the core X stuff that any desktop
spin would need (plus associated related scripts that all could make
use of like X auto login). From there a desktop based spin would just
need to pull in the base-desktop.ks to get all the core stuff to get
to a minimal X.
I believe the perferred state is that live-base would be preferred for
minimial spins and alternate desktop enivorments, and normal spins would
base off of livecd-desktop or live-desktop. So I think movement in that
direction would be good.
Again its getting late in the process for F14, but maybe some stuff get
get done for this release and other prep work can be done so that we
can get more changes into F15.
5:19 p.m.
On Tue, Aug 31, 2010 at 11:00 PM, Bruno Wolff III <bruno(a)wolff.to> wrote:
On Tue, Aug 31, 2010 at 22:48:48 +0100,
"pbrobinson(a)gmail.com" <pbrobinson(a)gmail.com> wrote:
>
> Firstly in fedora-live-minimization.ks and fedora-livecd-desktop.ks
> there's a whole lot of removal of packages. This is basically what i
> do in the fedora-live-mini.ks and I think things like @printing can
> (and should be) removed from base so that other kick starts don't have
> to explicitly remove everything that it adds in. Its easy enough for
> the people that want printing to add the one liner into their own
> kickstart.
I am not sure who owns the base (and core) definitons. Requesting a change
to make removing printing easier seems like a good idea.
I do have a question before we go that route though.
Would using -@printing work to drop the printing stuff before the deps
are brought in?
Unfortunately I think the minus only works on individual packages. I
did once try it but from memory its just ignored.
> Ultimately I would like to get rid of the fedora-live-mini.ks
file and
> use the mainline base. I believe that base should be exactly that...
> the base/core packages and all the useful scripting. Then possibly
> have a base-desktop which adds all the core X stuff that any desktop
> spin would need (plus associated related scripts that all could make
> use of like X auto login). From there a desktop based spin would just
> need to pull in the base-desktop.ks to get all the core stuff to get
> to a minimal X.
I believe the perferred state is that live-base would be preferred for
minimial spins and alternate desktop enivorments, and normal spins would
base off of livecd-desktop or live-desktop. So I think movement in that
direction would be good.
Again its getting late in the process for F14, but maybe some stuff get
get done for this release and other prep work can be done so that we
can get more changes into F15.
I realise that. I meant to bring this up just after F-13 came out,
unfortunately just before it came out I moved to a new position and
instantly got snowed under and I missed it. printing/fonts and some of
the input types bring in fairly large dependencies. The later two
might need some more work but printing seems to be the one that is
globally removed from most live images so it seems somewhat stupid to
include it in the base.
Peter
5:30 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 8/31/10 3:19 PM, pbrobinson(a)gmail.com wrote:
> > I do have a question before we go that route though.
> > Would using -@printing work to drop the printing stuff before the deps
> > are brought in?
Unfortunately I think the minus only works on individual packages. I
did once try it but from memory its just ignored.
I thought pykickstart added support for -@group recently. It could be
that the livecd tools don't make use of this yet.
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkx9gooACgkQ4v2HLvE71NX2PQCfY5aottA033w+/pOoSMvvQaZd
SQ0An3kzJrn6h4nJfDgQWcldiCqtlj63
=gtEh
-----END PGP SIGNATURE-----
5:41 p.m.
On Tue, Aug 31, 2010 at 11:30 PM, Jesse Keating <jkeating(a)redhat.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 8/31/10 3:19 PM, pbrobinson(a)gmail.com wrote:
>> > I do have a question before we go that route though.
>> > Would using -@printing work to drop the printing stuff before the deps
>> > are brought in?
> Unfortunately I think the minus only works on individual packages. I
> did once try it but from memory its just ignored.
>
I thought pykickstart added support for -@group recently. It could be
that the livecd tools don't make use of this yet.
It could be also that its been added and I wasn't aware of it, but the
later is also very likely given livecd-tools has seen very few changes
of late.
Even so I still see it as pointless that its added as default only to
be remove by many.
Peter
6:17 a.m.
On 01/09/10 08:41, pbrobinson(a)gmail.com wrote:
Even so I still see it as pointless that its added as default only
to
be remove by many.
I would like to think that people might not want to print to
tree, but
to pdf for transmission by email etc. It would be good to have a group
that provides this minimum functionality for any application that
provides printing capability.
(It wouldn't make sense to automatically include such a thing in every
livecd).
Again probably too late for group changes at this stage ?
Furthering Peter's email, what's the best place to track future plans
like this so that we can be reminded of them at the appropriate time ?
8:34 a.m.
On Tue, Sep 07, 2010 at 21:17:39 +1000,
David Timms <dtimms(a)iinet.net.au> wrote:
Again probably too late for group changes at this stage ?
Simple changes should still be fine, overhauls are not. I am not sure if
what you're proposing is simple or not.
Furthering Peter's email, what's the best place to track
future plans
like this so that we can be reminded of them at the appropriate time ?
Some places that make make sense:
An RFE bug against spin-kickstarts cc'd to relevant spin owners.
A spins trac ticket, again cc'd to relevant spin owners.
A comment on the discussion page for the relevant spin.
For spins that aren't tight on space adding things are easier. There are
a few where fitting on a CD or within the FAT size limit is important
and being able to do rare things might not be considered important enough.
Some spins inherit from the livecd desktop or live desktop depending on
whether or not they are tight on size. So by getting something added
to live desktop, it will probably get used by the spins that aren't
tightly constrained.
8:52 a.m.
On Tue, Sep 7, 2010 at 2:34 PM, Bruno Wolff III <bruno(a)wolff.to> wrote:
On Tue, Sep 07, 2010 at 21:17:39 +1000,
David Timms <dtimms(a)iinet.net.au> wrote:
>
> Again probably too late for group changes at this stage ?
Simple changes should still be fine, overhauls are not. I am not sure if
what you're proposing is simple or not.
> Furthering Peter's email, what's the best place to track future plans
> like this so that we can be reminded of them at the appropriate time ?
Some places that make make sense:
An RFE bug against spin-kickstarts cc'd to relevant spin owners.
A spins trac ticket, again cc'd to relevant spin owners.
A comment on the discussion page for the relevant spin.
For spins that aren't tight on space adding things are easier. There are
a few where fitting on a CD or within the FAT size limit is important
and being able to do rare things might not be considered important enough.
Some spins inherit from the livecd desktop or live desktop depending on
whether or not they are tight on size. So by getting something added
to live desktop, it will probably get used by the spins that aren't
tightly constrained.
In some cases this is actually changes to the comps xml file so it has
possible (although in most cases due to rpm deps unlikely) wider
ranging effect than just on spins.
Peter
4977
days inactive
4984
days old
7 comments
4 participants
participants (4)
-
Bruno Wolff III -
Development discussions related to Fedora -
Jesse Keating -
Peter Robinson