I've been playing to see how much more we can fit on the live CD for test 2.

First, I eliminated docs from the livecd with a patch to livecd-creator (attached).

Then, I started adding and removing things. Based on Jeremy's test1 configs at http://people.redhat.com/katzj/f7live/, I made the following changes:

Added ----- attr bind-utils gnome-screensaver pcmciautils termcap crontabs ppp rp-pppoe wvdial logrotate mdadm smolt nfs-utils readahead

rhgb

gok gnome-backgrounds gnome-audio nautilus-sendto nautilus-sendto-bluetooth monkey-bubble gnome-blog

Removed ------- emacs xchat-gnome

> Didn't add any of these and I'm at ~ 15 megs to spare. So some could > be, but probably not all of them without the --nodocs bits So, somehow this spin is now averaging between 706MB and 714MB on my trials - it *shouldn't* be that big. Will do more investigating.

--- Bill Nottingham <notting(a)redhat.com&gt; wrote: > Jeremy Katz (katzj(a)redhat.com) said: > > > First, I eliminated docs from the livecd with a patch to > > > livecd-creator (attached). > > > > Hmm... I'm not sure if we really want to do this unconditionally. > And > > given that we later can install from the live CD, is removing the > docs > > something we really want to do? > > It's stuff in /usr/share/doc and info pages. Are either of those > appropriate for a *Desktop* livecd? While I agree that ruthlessly nuking things like /usr/share/doc is a useful way to make your livecd image smaller, it seems like a bad thing to me for the case here. In addition to Jeremy's point, I'll just throw in my anecdotal usage example- firefox file:///usr/share/doc/qemu-bla/index.html Is wanting to read the manual for the software you are using on a livecd something that "doesn't make sense for a *desktop* livecd". I think the answer is no. (but again, having several flags to livecd-creator to prune your target tree in typical ways (e.g. nuking usr/share/doc, or /var/lib/rpm) does seem useful to me for the general livecd generation case).

Jane Dogalt (jdogalt(a)yahoo.com) said: > While I agree that ruthlessly nuking things like /usr/share/doc is a > useful way to make your livecd image smaller, it seems like a bad thing > to me for the case here. In addition to Jeremy's point, I'll just > throw in my anecdotal usage example- > > firefox file:///usr/share/doc/qemu-bla/index.html > > Is wanting to read the manual for the software you are using on a > livecd something that "doesn't make sense for a *desktop* livecd". I > think the answer is no. Maybe I'm weird, but I think the stock target for a 'desktop' livecd probably isn't ever invoking qemu from the command line. The idea is that help & docs for the things we'd ship on a desktop should be part & parcel of the apps themselves, not random things hidden away in /usr/share/doc that someone needs to know to look for.

Jane Dogalt (jdogalt(a)yahoo.com) said: > IMO /usr/share/doc is where manuals are supposed to go. Are you > suggesting they be binary encoded in the app for all applications? As > an anecdotal developer, I have plans on developing software which keeps > its documentation in html form under /usr/share/doc just like qemu, > because it just seems like the right packaging style choice. Of course > I haven't yet read all the fedora packaging guidelines... If it's an actual help document that comes up on <F1> (or whatever), it should probably go in some portion of %{_datadir}.

I always thought it seemed nice if when you launched your help documents in the app (with F1 or whatever) that that spawned "htmlviewer file:///usr/share/doc/myapp-version/index.html" Thus if that were a packaging guideline, or even unspoken consensus, then people would always have a consistent way to reach the documentation. (and embedded systems developers who were really tight on memory requirements would have an easy way to nuke all the documentation at once).