[Fedora-livecd-list] Re: patch review and move of livecd scm

Jesse Keating jkeating at redhat.com
Thu Mar 8 21:20:01 UTC 2007


On Thursday 08 March 2007 12:29:23 David Zeuthen wrote:
> Sigh... Why didn't you just say so in the first place instead of coming
> up with broken reasons like running software from NFS (on the livecd
> even!) and the like? I still think it's really silly but, yeah,
> sometimes we do inconvenience the user to show of features.

Probably because as the argument progressed I remembered some of why we do 
this for the actual install in the first place. (:

> > We spent a lot of time and effort
> > to make it work a best we could, when other distributions decided to just
> > pass on it.  Removing this functionality from something we'll want to be
> > able to use to show off our features seems like a bad decision to me.
> >  The damned constraint of 700megs is what kills us time and time again,
> > and it will only get worse.
>
> We also include a lot of useless crap due to packaging bugs like
>
>  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229442

Yeah, it is good to find these things now that we're putting our software back 
into constrained areas, like a LiveCD and OLPC.  More splitting is sometimes 
good, but at the same time there is the cost of feature discoverability.  I 
installed <foo> and tried to do <bar> with it, but I couldn't so I gave up on 
<foo> not realizing that I had to install <foo>-<bar> in order to get that 
functionality.  It's an ugly problem :/

> and also a ton of duplicate artwork etc. When I worked on OLPC we
> managed to fix some of this, including silly dependencies like the X
> server pulling in perl. I'm fearing it's slowly creeping in again:
>
>  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230056

Yes, proper packaging rules do expose some packaging issues like this.  The 
solution isn't to ignore the rules, it's to adjust the package so that they 
follow the rules to promote proper packaging.  We don't just make up these 
rules because we think they're fun, there are problems and concerns around 
most of these beyond just "consistency".

> I guess keeping bloat to a minimum is not fashionable these days and to
> some people "more packages == better product". Sad.

Where are you seeing that?  I think it is more "more package options == better 
product" not more packages in the install or spin.    More options, more 
thoughts/discussion/experminitation on how to cut them up leads to better 
experiences.

> Here's a constructive idea: perhaps someone should investigate the price
> difference on the cost of creating DVD media vs. CD media. To me it
> sounds like you think it's zero. I haven't checked for a while though;
> perhaps Greg knows as he is getting media prepared?

Perhaps he does.  Lets CC him and find out. 

> Then, there's also the bandwidth issues; the more we include on the
> livecd (which will get installed), the more updates our users will have
> to download and in some regions bandwidth is extremely scarce.

Very true.

> >   The functionality of our LiveCD will only get worse over time if
> > we stick to CD size.  Perhaps we do only DVD live images for multiarch
> > platforms.  The tool set should still allow for creating a single arch
> > x86_64 CD, but that isn't something I want to publish as any sort of
> > official Fedora release.
>
> Well, I can hear it's certainly not my call so I'll just be quiet.

It's not my call alone either.  Ultimately it is the Fedora Board's call if we 
can't all come to an agreement.

-- 
Jesse Keating
Release Engineer: Fedora
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-livecd-list/attachments/20070308/c022de0b/attachment.sig>


More information about the Fedora-livecd-list mailing list