patch, manifest changes

[Bill Nottingham]

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

This yields a 678MB Live CD, so we've still got a decent
amount of room for changes.

(SRPM for fedora-livecd attached)

Bill

[Jeremy Katz]

On Fri, 2007-02-23 at 13:46 -0500, Bill Nottingham wrote:
> I've been playing to see how much more we can fit on the live
> CD for test 2.

Always the fun part (or not)
> 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?
> 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:

Those bits are now at http://people.redhat.com/katzj/live/f7test1/ but a
symlink points there.  I've put up what I've used for a proto-test2 live
CD at http://people.redhat.com/katzj/live/f7test2pre (and I'll try and
keep that current)
> Added
>
> attr
> bind-utils
> gnome-screensaver
> pcmciautils
> termcap
> crontabs
> ppp
> rp-pppoe
> wvdial
> logrotate
> mdadm
> smolt
> nfs-utils
> readahead

These are all in my list
> rhgb

Not added because it's incredibly painful for a live CD right now...
and I keep hoping that we're going to get to kill rhgb before F7.
Although the chances of that seem to be dwindling :(
> gok
> gnome-backgrounds
> gnome-audio
> nautilus-sendto
> nautilus-sendto-bluetooth
> monkey-bubble
> gnome-blog

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
> Removed
>
> emacs
> xchat-gnome

I took out xchat-gnome, emacs is still there.  It's probably worth
killing for some subset of the above too.

Jeremy

[Bill Nottingham]

Jeremy Katz ([e-mail]) 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?
> Those bits are now at http://people.redhat.com/katzj/live/f7test1/ but a
> symlink points there.  I've put up what I've used for a proto-test2 live
> CD at http://people.redhat.com/katzj/live/f7test2pre (and I'll try and
> keep that current)

OK, will look at what I have and rediff.
> > gok
> > gnome-backgrounds
> > gnome-audio
> > nautilus-sendto
> > nautilus-sendto-bluetooth
> > monkey-bubble
> > gnome-blog
>
> 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

[Bill Nottingham]

Bill Nottingham ([e-mail]) said:
> > 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.

This is because of gok -> gnome-speech -> festival.

I built with the attached diff, and got 681MB, so we've still got
some wiggle room.

Bill

[Jane Dogalt]

--- Bill Nottingham  wrote:
> Jeremy Katz ([e-mail]) 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).

-dmc/jdog

____________________________________________________________________________________
Sucker-punch spam with award-winning protection. 
Try the free Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/features_spam.html

[Jane Dogalt]

--- Jane Dogalt  wrote:
> --- Bill Nottingham  wrote:
> > Jeremy Katz ([e-mail]) 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).

Another idea I've often kicked around, which may have already been
thoroughly discounted on other mailinglists is this-

Have rpms maintain a notion of-

* required files
* files that are nice to have
* files that might be useful to someone somewhere somtime

And when you install the rpm, you specify which of the 3 levels you
desire (or maybe rpm looks at how much disk space you have and decides
for you).  Along with easy tools to 'upgrade' yourself to a different
level with yum/rpm after the initial install.

I.e. the first level (required) would be with low memory embedded
systems in mind.

Another scenario where it comes in useful, is you do your install with
the full level, then later you run into a time when you are running out
of disk space and you need a simple solution, so you just run a command
to downgrade every package.

just a though...

-dmc/jdog

____________________________________________________________________________________
Want to start your own business?
Learn how on Yahoo! Small Business.
http://smallbusiness.yahoo.com/r-index

[Bill Nottingham]

Jane Dogalt ([e-mail]) 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.

Bill

[Jane Dogalt]

--- Bill Nottingham  wrote:
> Jane Dogalt ([e-mail]) 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.

Setting asside my estimations of qemu's usefulness...

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...

-dmc/jdog

____________________________________________________________________________________
No need to miss a message. Get email on-the-go 
with Yahoo! Mail for Mobile. Get started.
http://mobile.yahoo.com/mail

[Bill Nottingham]

Jane Dogalt ([e-mail]) 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}.

Bill

[Jane Dogalt]

--- Bill Nottingham  wrote:
> Jane Dogalt ([e-mail]) 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).

-dmc/jdog

____________________________________________________________________________________
Now that's room service!  Choose from over 150,000 hotels
in 45,000 destinations on Yahoo! Travel to find your fit.
http://farechase.yahoo.com/promo-generic-14795097

[Jeremy Katz]

(... we are rapidly becoming off-topic for this list)

On Mon, 2007-02-26 at 09:17 -0800, Jane Dogalt wrote:
> --- Bill Nottingham  wrote:
> > Jane Dogalt ([e-mail]) 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).

Really, you don't want to spawn htmlview, you want to integrate with the
help view system of your desktop.  For GNOME, that means yelp and
scrollkeeper.  And libgnome provides a pretty easy way to integrate with
your help by launching yelp, etc.

Jeremy

[Bill Nottingham]

Jane Dogalt ([e-mail]) said:
> 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).

Well, if we ever go to differential updates, %{_datadir}/myapp
rather than /usr/share/doc/myapp-%{version} will make a difference
in update size.

Bill