Trimming the size of LiveCD's

[Jeroen van Meeuwen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Here's a thought:

1304 random packages will install 724 MB of data in /usr/share/doc

I'm sure there is /something/ to gain here. If every package on average
installs ~0.5 MB of docs... Would it worth figuring out what docs should
be on the LiveCD in the first place? I guess removing everything RPM
calls docs is too much, as this will include man-pages as well.

Any thoughts?

- --
Kind regards,

Jeroen van Meeuwen
- -kanarip

- --
http://www.kanarip.com/
RHCE, LPIC-2, MCP, CCNA
C6B0 7FB4 43E6 CDDA D258  F70B 28DE 9FDA 9342 BF08
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
>
> iD8DBQFG19BDKN6f2pNCvwgRAhhaAJ9UCH9WetRBu6foxAgztqMvg3h6OwCeLZU5
> LxWzG5TBxdQOAE3VGFp400w=
> =YiuK
> -----END PGP SIGNATURE-----

[Tim Lauridsen]

Jeroen van Meeuwen wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
>  Here's a thought:
>
>  1304 random packages will install 724 MB of data in /usr/share/doc
>
>  I'm sure there is /something/ to gain here. If every package on average
>  installs ~0.5 MB of docs... Would it worth figuring out what docs should
>  be on the LiveCD in the first place? I guess removing everything RPM
>  calls docs is too much, as this will include man-pages as well.
>
>  Any thoughts?
>
>     
I think it is a bad idea, because many people uses the Live CD's to 
install to their systems, and then they end up with a system
without doc files, with no easy way to get the docs back on the systems.

Tim

[Jeroen van Meeuwen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tim Lauridsen wrote:
>  Jeroen van Meeuwen wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Here's a thought:
> >
> > 1304 random packages will install 724 MB of data in /usr/share/doc
> >
> > I'm sure there is /something/ to gain here. If every package on average
> > installs ~0.5 MB of docs... Would it worth figuring out what docs should
> > be on the LiveCD in the first place? I guess removing everything RPM
> > calls docs is too much, as this will include man-pages as well.
> >
> > Any thoughts?
> >
> >   
>  I think it is a bad idea, because many people uses the Live CD's to
>  install to their systems, and then they end up with a system
>  without doc files, with no easy way to get the docs back on the systems.
>   
That's not true as anaconda needs the RPMs to install to a system,
right? Last time I checked a LiveCD could not be installed "offline"
because of this.

- --
Kind regards,

Jeroen van Meeuwen
- -kanarip

- --
http://www.kanarip.com/
RHCE, LPIC-2, MCP, CCNA
C6B0 7FB4 43E6 CDDA D258  F70B 28DE 9FDA 9342 BF08
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
>
> iD8DBQFG19fTKN6f2pNCvwgRAs7bAJ9UrHYNddpRhOq2Ezmo2mSV7hnzugCfe45p
> 1XKG7iFgRoWYmRK4URgZ510=
> =whWy
> -----END PGP SIGNATURE-----

[Douglas McClendon]

Jeroen van Meeuwen wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>  
>  Tim Lauridsen wrote:
> > Jeroen van Meeuwen wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Here's a thought:
> >>
> >> 1304 random packages will install 724 MB of data in /usr/share/doc
> >>
> >> I'm sure there is /something/ to gain here. If every package on average
> >> installs ~0.5 MB of docs... Would it worth figuring out what docs should
> >> be on the LiveCD in the first place? I guess removing everything RPM
> >> calls docs is too much, as this will include man-pages as well.
> >>
> >> Any thoughts?
> >>
> >>   
> > I think it is a bad idea, because many people uses the Live CD's to
> > install to their systems, and then they end up with a system
> > without doc files, with no easy way to get the docs back on the systems.
> >
>  
>  That's not true as anaconda needs the RPMs to install to a system,
>  right? Last time I checked a LiveCD could not be installed "offline"
>  because of this. 
I think you really need to check again.  The current liveinst installer 
(which uses the LiveCDCopy anaconda backend) does not need the rpms, it 
just copies the ext3 filesystem image block for block from the livecd to 
the disk.  i.e. all those threads in the past about the livecd installer 
wiping the root partition, formatting the root partition twice, being 
able to be sped up by 20+% with my turboLiveInst patch that jeremy is 
afraid of, etc...

-dmc

[Jeroen van Meeuwen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Douglas McClendon wrote:
>  Jeroen van Meeuwen wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Tim Lauridsen wrote:
> >> Jeroen van Meeuwen wrote:
> >>> -----BEGIN PGP SIGNED MESSAGE-----
> >>> Hash: SHA1
> >>>
> >>> Here's a thought:
> >>>
> >>> 1304 random packages will install 724 MB of data in /usr/share/doc
> >>>
> >>> I'm sure there is /something/ to gain here. If every package on average
> >>> installs ~0.5 MB of docs... Would it worth figuring out what docs
> >>> should
> >>> be on the LiveCD in the first place? I guess removing everything RPM
> >>> calls docs is too much, as this will include man-pages as well.
> >>>
> >>> Any thoughts?
> >>>
> >>>   
> >> I think it is a bad idea, because many people uses the Live CD's to
> >> install to their systems, and then they end up with a system
> >> without doc files, with no easy way to get the docs back on the systems.
> >>
> >
> > That's not true as anaconda needs the RPMs to install to a system,
> > right? Last time I checked a LiveCD could not be installed "offline"
> > because of this.
>  
>  I think you really need to check again.  The current liveinst installer
>  (which uses the LiveCDCopy anaconda backend) does not need the rpms, it
>  just copies the ext3 filesystem image block for block from the livecd to
>  the disk.  i.e. all those threads in the past about the livecd installer
>  wiping the root partition, formatting the root partition twice, being
>  able to be sped up by 20+% with my turboLiveInst patch that jeremy is
>  afraid of, etc...
>   
Should the way liveinst installer installs to the user's system limit
what space we can save on a LiveCD? I don't think so. Just like there's
a use-case for installing from a LiveCD, there's a use case for "rm
- -rf'ing" as much as one can to save space on the Live Media.

Does liveinst still support installing from RPMs as well?

- --
Kind regards,

Jeroen van Meeuwen
- -kanarip

- --
http://www.kanarip.com/
RHCE, LPIC-2, MCP, CCNA
C6B0 7FB4 43E6 CDDA D258  F70B 28DE 9FDA 9342 BF08
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
>
> iD8DBQFG19zZKN6f2pNCvwgRAgYJAJwK5MhN2SslOx2VBkwdu9BcqJ4rEgCgr+i5
> ujfwwGgYMBYXOpc71jZ6M34=
> =pUml
> -----END PGP SIGNATURE-----

[Douglas McClendon]

Jeroen van Meeuwen wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>  
>  Douglas McClendon wrote:
> > Jeroen van Meeuwen wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Tim Lauridsen wrote:
> >>> Jeroen van Meeuwen wrote:
> >>>> -----BEGIN PGP SIGNED MESSAGE-----
> >>>> Hash: SHA1
> >>>>
> >>>> Here's a thought:
> >>>>
> >>>> 1304 random packages will install 724 MB of data in /usr/share/doc
> >>>>
> >>>> I'm sure there is /something/ to gain here. If every package on
> average
> >>>> installs ~0.5 MB of docs... Would it worth figuring out what docs
> >>>> should
> >>>> be on the LiveCD in the first place? I guess removing everything RPM
> >>>> calls docs is too much, as this will include man-pages as well.
> >>>>
> >>>> Any thoughts?
> >>>>
> >>>>   
> >>> I think it is a bad idea, because many people uses the Live CD's to
> >>> install to their systems, and then they end up with a system
> >>> without doc files, with no easy way to get the docs back on the systems.
> >>>
> >> That's not true as anaconda needs the RPMs to install to a system,
> >> right? Last time I checked a LiveCD could not be installed "offline"
> >> because of this.
> > I think you really need to check again.  The current liveinst installer
> > (which uses the LiveCDCopy anaconda backend) does not need the rpms, it
> > just copies the ext3 filesystem image block for block from the livecd to
> > the disk.  i.e. all those threads in the past about the livecd installer
> > wiping the root partition, formatting the root partition twice, being
> > able to be sped up by 20+% with my turboLiveInst patch that jeremy is
> > afraid of, etc...
> >
>  
>  Should the way liveinst installer installs to the user's system limit
>  what space we can save on a LiveCD? I don't think so. Just like there's
>  a use-case for installing from a LiveCD, there's a use case for "rm
>  - -rf'ing" as much as one can to save space on the Live Media. 
In my other reply, I pointed out that recovering rm-d things easily, is
not a hard problem to solve.  But certainly something that doesn't
currently work, and would require some new mechanism (either explicit on
the user's part, or just that yum will implicitly replace the missing
stuff the next time it has access to rpms that the missing stuff can be
extracted from).

Don't misunderstand me-  I have in no way suggested that there was 
anything wrong with your idea of removing things (spec documentation) 
that the livecd user might be perfectly willing to live without (until 
such time as they have access to the network to reinstall it, as 
mentioned above).


>  
>  Does liveinst still support installing from RPMs as well? 
/usr/(s)bin/liveinst is a bash wrapper around anaconda, that invokes
anaconda in a special way so that it uses the livecd filesystem
duplication method, instead of rpms.

The (perfectly normal) anaconda on the livecd, if invoked without the
liveinst wrapper, is capable of installing from a network or local
repository of rpms.  Though for obvious reasons, no local repository of
rpms has been included on the livecds.

-dmc

[Jeroen van Meeuwen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Douglas McClendon wrote:
>  /usr/(s)bin/liveinst is a bash wrapper around anaconda, that invokes
>  anaconda in a special way so that it uses the livecd filesystem
>  duplication method, instead of rpms.
>  
>  The (perfectly normal) anaconda on the livecd, if invoked without the
>  liveinst wrapper, is capable of installing from a network or local
>  repository of rpms.  Though for obvious reasons, no local repository of
>  rpms has been included on the livecds.
>   
It seems to me that if a livecd removes shit to save space, and anaconda
can still use a CD with RPM's on it, the problem of not being able to
install from a LiveCD is solved; Install from a LiveCD with stripped
contents using another CD that holds the RPMs.

However this may not be applicable to any of the Live Media the Fedora
Project releases, I see a use-case for *anyone else* wanting to produce
Live Media.

Back to the original topic; what could we possibly remove without all
"help" functions b0rking. I'm thinking INSTALL, ChangeLog/CHANGES,
README, etc files, as well as maybe a number of non-prominent utility
documentation sets (from the end-user POV, zlib-x.x.x documentation
really isn't relevant). For some packages even, we could maybe remove
the man pages as well (--excludedocs in extreme cases?)

- --
Kind regards,

Jeroen van Meeuwen
- -kanarip

- --
http://www.kanarip.com/
RHCE, LPIC-2, MCP, CCNA
C6B0 7FB4 43E6 CDDA D258  F70B 28DE 9FDA 9342 BF08
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
>
> iD8DBQFG1+WpKN6f2pNCvwgRAkz/AJ4/M11J5iLZdUrNGKmob2mmQQMeJACfWOsq
> rI7PW9FHfV6fbZ3m7dwCcWw=
> =keSi
> -----END PGP SIGNATURE-----

Perhaps a switch will enable --excludedocs on rpms being installed into
the live-cd and a tweak to yum would enable someone who liveinsts the
livecd to a disk to type run some new cmd like "yum updatedocs" or
something that gets the docs back?

To take this another level, stuff in rpms can be flagged as necessary /
extra and there can be an --excludeextras flag during rpm install and a
yum updateextras or yum installextras command to go add these back in?

Thanks,

MoeK

-----Original Message-----
From: fedora-livecd-list-bounces(a)redhat.com
[mailto:[e-mail]] On Behalf Of Jeroen van
Meeuwen
Sent: Friday, August 31, 2007 4:56 AM
To: fedora-livecd-list(a)redhat.com
Subject: Re: [Fedora-livecd-list] Trimming the size of LiveCD's

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Douglas McClendon wrote:
>  /usr/(s)bin/liveinst is a bash wrapper around anaconda, that invokes
>  anaconda in a special way so that it uses the livecd filesystem
>  duplication method, instead of rpms.
>  
>  The (perfectly normal) anaconda on the livecd, if invoked without the
>  liveinst wrapper, is capable of installing from a network or local
>  repository of rpms.  Though for obvious reasons, no local repository 
of
>  rpms has been included on the livecds.
>   
It seems to me that if a livecd removes shit to save space, and anaconda
can still use a CD with RPM's on it, the problem of not being able to
install from a LiveCD is solved; Install from a LiveCD with stripped
contents using another CD that holds the RPMs.

However this may not be applicable to any of the Live Media the Fedora
Project releases, I see a use-case for *anyone else* wanting to produce
Live Media.

Back to the original topic; what could we possibly remove without all
"help" functions b0rking. I'm thinking INSTALL, ChangeLog/CHANGES,
README, etc files, as well as maybe a number of non-prominent utility
documentation sets (from the end-user POV, zlib-x.x.x documentation
really isn't relevant). For some packages even, we could maybe remove
the man pages as well (--excludedocs in extreme cases?)

- --
Kind regards,

Jeroen van Meeuwen
- -kanarip

- --
http://www.kanarip.com/
RHCE, LPIC-2, MCP, CCNA
C6B0 7FB4 43E6 CDDA D258  F70B 28DE 9FDA 9342 BF08
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
>
> iD8DBQFG1+WpKN6f2pNCvwgRAkz/AJ4/M11J5iLZdUrNGKmob2mmQQMeJACfWOsq
> rI7PW9FHfV6fbZ3m7dwCcWw=
> =keSi
> -----END PGP SIGNATURE----- 
--
Fedora-livecd-list mailing list
Fedora-livecd-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-livecd-list

[Elias Hunt]

I'm just getting caught up on some old threads, but saw this one and
wanted to add another voice in support.

Since rpm itself already supports the --excludedocs argument, does yum
support passthrough? If so could livecd-creator also support passthrough
in some way? I looked at the livecd-creator code in hopes of being able
to submit a patch myself, but I understand entirely too little of the
yum api and whether or not it would support passing along standard rpm
arguments or if yum itself might need to be modified.

In the past when we did our own custom spins (not livecd-creator based)
I used to do cleanup of info, man, docs, etc by removing the files from
my master image. This allowed all spins to not even have to think about
those files. As was suggested in this thread the files could be removed
in the %post section, however that means time, disk and RAM would be
utilized during the spinning process to install and then delete the
files. If they never got installed in the first place it seems like the
whole thing would be smoother.

In our case we'd never want those files back as we don't install off
livecds, so having a tool to fix would be inconsequential. Obviously
this should never be enabled by default, but for many of us making
custom spins it seems like a quick way to remove a lot of excess data at
a cost we'd be willing to bear.

If there is already an argument available in kickstart, yum or
livecd-creator that can do this, I'd appreciate the slap on the wrist
and being told I should pay more attention. :)

Thanks.
-Eli

-----Original Message-----
From: fedora-livecd-list-bounces(a)redhat.com
[mailto:[e-mail]] On Behalf Of
Mohammed_Khan(a)Dell.com
Sent: Friday, August 31, 2007 11:03 AM
To: fedora-livecd-list(a)redhat.com
Subject: RE: [Fedora-livecd-list] Trimming the size of LiveCD's

Perhaps a switch will enable --excludedocs on rpms being installed into
the live-cd and a tweak to yum would enable someone who liveinsts the
livecd to a disk to type run some new cmd like "yum updatedocs" or
something that gets the docs back?

To take this another level, stuff in rpms can be flagged as necessary /
extra and there can be an --excludeextras flag during rpm install and a
yum updateextras or yum installextras command to go add these back in?

Thanks,

MoeK

-----Original Message-----
From: fedora-livecd-list-bounces(a)redhat.com
[mailto:[e-mail]] On Behalf Of Jeroen van
Meeuwen
Sent: Friday, August 31, 2007 4:56 AM
To: fedora-livecd-list(a)redhat.com
Subject: Re: [Fedora-livecd-list] Trimming the size of LiveCD's

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Douglas McClendon wrote:
>  /usr/(s)bin/liveinst is a bash wrapper around anaconda, that invokes
>  anaconda in a special way so that it uses the livecd filesystem
>  duplication method, instead of rpms.
>  
>  The (perfectly normal) anaconda on the livecd, if invoked without the
>  liveinst wrapper, is capable of installing from a network or local
>  repository of rpms.  Though for obvious reasons, no local repository 
of
>  rpms has been included on the livecds.
>   
It seems to me that if a livecd removes shit to save space, and anaconda
can still use a CD with RPM's on it, the problem of not being able to
install from a LiveCD is solved; Install from a LiveCD with stripped
contents using another CD that holds the RPMs.

However this may not be applicable to any of the Live Media the Fedora
Project releases, I see a use-case for *anyone else* wanting to produce
Live Media.

Back to the original topic; what could we possibly remove without all
"help" functions b0rking. I'm thinking INSTALL, ChangeLog/CHANGES,
README, etc files, as well as maybe a number of non-prominent utility
documentation sets (from the end-user POV, zlib-x.x.x documentation
really isn't relevant). For some packages even, we could maybe remove
the man pages as well (--excludedocs in extreme cases?)

- --
Kind regards,

Jeroen van Meeuwen
- -kanarip

- --
http://www.kanarip.com/
RHCE, LPIC-2, MCP, CCNA
C6B0 7FB4 43E6 CDDA D258  F70B 28DE 9FDA 9342 BF08
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
>
> iD8DBQFG1+WpKN6f2pNCvwgRAkz/AJ4/M11J5iLZdUrNGKmob2mmQQMeJACfWOsq
> rI7PW9FHfV6fbZ3m7dwCcWw=
> =keSi
> -----END PGP SIGNATURE----- 
--
Fedora-livecd-list mailing list
Fedora-livecd-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-livecd-list

--
Fedora-livecd-list mailing list
Fedora-livecd-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-livecd-list

[Jeremy Katz]

On Tue, 2007-10-02 at 15:26 -0400, Elias Hunt wrote:
>  Since rpm itself already supports the --excludedocs argument, does
> yum
>  support passthrough? If so could livecd-creator also support passthrough
>  in some way? I looked at the livecd-creator code in hopes of being able
>  to submit a patch myself, but I understand entirely too little of the
>  yum api and whether or not it would support passing along standard rpm
>  arguments or if yum itself might need to be modified. 
It should be pretty straight-forward.  pykickstart already parses a
--excludedocs argument to %packages.  When that argument is given, we
just need to set the rpm macro _excludedocs to 1.  If someone wants to
whip up the patch, I would have no problem at all applying it

Jeremy

[Elias Hunt]

I believe I've done this correctly based on the way other kickstart data
is used, but I'm not particularly familiar with python.

I won't be able to test this until at least tomorrow, but wanted to
submit it in case someone can tell me it's completely broken, there's a
better way, or in case I hit the nail on the head and it can be merged
sooner rather than later.

Thanks.
-Eli

-----Original Message-----
From: fedora-livecd-list-bounces(a)redhat.com
[mailto:[e-mail]] On Behalf Of Jeremy Katz
Sent: Tuesday, October 02, 2007 4:04 PM
To: fedora-livecd-list(a)redhat.com
Subject: RE: [Fedora-livecd-list] Trimming the size of LiveCD's

On Tue, 2007-10-02 at 15:26 -0400, Elias Hunt wrote:
>  Since rpm itself already supports the --excludedocs argument, does
> yum
>  support passthrough? If so could livecd-creator also support 
passthrough
>  in some way? I looked at the livecd-creator code in hopes of being
able
>  to submit a patch myself, but I understand entirely too little of
> the
>  yum api and whether or not it would support passing along standard rpm
>  arguments or if yum itself might need to be modified. 
It should be pretty straight-forward.  pykickstart already parses a
--excludedocs argument to %packages.  When that argument is given, we
just need to set the rpm macro _excludedocs to 1.  If someone wants to
whip up the patch, I would have no problem at all applying it

Jeremy

--
Fedora-livecd-list mailing list
Fedora-livecd-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-livecd-list

[Jeremy Katz]

On Tue, 2007-10-02 at 17:09 -0400, Elias Hunt wrote:
>  I believe I've done this correctly based on the way other
> kickstart data
>  is used, but I'm not particularly familiar with python.
>  
>  I won't be able to test this until at least tomorrow, but wanted to
>  submit it in case someone can tell me it's completely broken, there's a
>  better way, or in case I hit the nail on the head and it can be merged
>  sooner rather than later. 
Looks reasonable...  might be worth moving the bits into
installPackages() just to make it look a little cleaner.  And a test
confirming it works as expected would be nice.  I'll try to get to doing
so tomorrow, but depends on how the day goes

Jeremy

[Elias Hunt]

Jeremy,
Original patch had a typo. I've also moved the setting of excludedocs to
the top of the installPackages() function as suggested.

During testing I got this error:
/usr/lib/python2.5/site-packages/pykickstart/options.py:83:
DeprecationWarning: Ignoring deprecated option on line 14:  The
--excludedocs option has been deprecated and no longer has any effect.
It may be removed from future releases, which will result in a fatal
error from kickstart.  Please modify your kickstart file to remove this
option.
  warnings.warn(_("Ignoring deprecated option on line %(lineno)s:  The
%(option)s option has been deprecated and no longer has any effect.  It
may be removed from future releases, which will result in a fatal error
from kickstart.  Please modify your kickstart file to remove this
option.") % mapping, DeprecationWarning)

Are we sure that kickstart isn't planning to get rid of that option? Or
is this just a symptom of my using a Fedora 7 build system?

Either way, I've just completed a test burn and it appears that docs,
info and man pages were not installed to the CD, as expected. There were
some directories and symlinks created within those directories, but I'd
assume that is bad behavior in various RPMs and has nothing to do with
the functionality within livecd-creator.

Thanks.
-Eli

-----Original Message-----
From: fedora-livecd-list-bounces(a)redhat.com
[mailto:[e-mail]] On Behalf Of Jeremy Katz
Sent: Tuesday, October 02, 2007 5:25 PM
To: fedora-livecd-list(a)redhat.com
Subject: RE: [Fedora-livecd-list] Trimming the size of LiveCD's

On Tue, 2007-10-02 at 17:09 -0400, Elias Hunt wrote:
>  I believe I've done this correctly based on the way other
> kickstart 
data
>  is used, but I'm not particularly familiar with python.
>  
>  I won't be able to test this until at least tomorrow, but wanted to
>  submit it in case someone can tell me it's completely broken, there's 
a
>  better way, or in case I hit the nail on the head and it can be
> merged
>  sooner rather than later. 
Looks reasonable...  might be worth moving the bits into
installPackages() just to make it look a little cleaner.  And a test
confirming it works as expected would be nice.  I'll try to get to doing
so tomorrow, but depends on how the day goes

Jeremy

--
Fedora-livecd-list mailing list
Fedora-livecd-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-livecd-list

[Jeremy Katz]

On Wed, 2007-10-03 at 09:04 -0400, Elias Hunt wrote:
>  Original patch had a typo. I've also moved the setting of
> excludedocs to
>  the top of the installPackages() function as suggested. 
Thanks!

>  During testing I got this error:
>  /usr/lib/python2.5/site-packages/pykickstart/options.py:83:
>  DeprecationWarning: Ignoring deprecated option on line 14:  The
>  --excludedocs option has been deprecated and no longer has any effect.
>  It may be removed from future releases, which will result in a fatal
>  error from kickstart.  Please modify your kickstart file to remove this
>  option. 
[snip]
>  Are we sure that kickstart isn't planning to get rid of that
> option? Or
>  is this just a symptom of my using a Fedora 7 build system? 
We had talked about it at one point.  Given kickstart being used beyond
anaconda, I talked Chris into pulling the deprecated bit and so the
warning will be gone as of pykickstart-1.16

>  Either way, I've just completed a test burn and it appears that
> docs,
>  info and man pages were not installed to the CD, as expected. There were
>  some directories and symlinks created within those directories, but I'd
>  assume that is bad behavior in various RPMs and has nothing to do with
>  the functionality within livecd-creator. 
Yep, sounds good.  Applied the patch to my tree and pushed to the git
master.

Thanks!

Jeremy

[Tim Lauridsen]

Jeroen van Meeuwen wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
>  Tim Lauridsen wrote:
>    
> > Jeroen van Meeuwen wrote:
> >     
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Here's a thought:
> >>
> >> 1304 random packages will install 724 MB of data in /usr/share/doc
> >>
> >> I'm sure there is /something/ to gain here. If every package on average
> >> installs ~0.5 MB of docs... Would it worth figuring out what docs should
> >> be on the LiveCD in the first place? I guess removing everything RPM
> >> calls docs is too much, as this will include man-pages as well.
> >>
> >> Any thoughts?
> >>
> >>   
> >>       
> > I think it is a bad idea, because many people uses the Live CD's to
> > install to their systems, and then they end up with a system
> > without doc files, with no easy way to get the docs back on the systems.
> >
> >     
>
>  That's not true as anaconda needs the RPMs to install to a system,
>  right? Last time I checked a LiveCD could not be installed "offline"
>  because of this.
>     
The Live CD installer just copy the whole system on the Live CD to the 
local hard drive, and make some changes, it don't use any rpms.

Tim

[Douglas McClendon]

Tim Lauridsen wrote:
>  Jeroen van Meeuwen wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Here's a thought:
> >
> > 1304 random packages will install 724 MB of data in /usr/share/doc
> >
> > I'm sure there is /something/ to gain here. If every package on average
> > installs ~0.5 MB of docs... Would it worth figuring out what docs should
> > be on the LiveCD in the first place? I guess removing everything RPM
> > calls docs is too much, as this will include man-pages as well.
> >
> > Any thoughts?
> >
> >   
>  I think it is a bad idea, because many people uses the Live CD's to 
>  install to their systems, and then they end up with a system
>  without doc files, with no easy way to get the docs back on the systems. 
That's really not such a hard thing to fix - the easy way to get things 
back after installation.

It also relates to a feature I proposed a long time ago

"yum spininstall"

Which would be an easy way to take a livecd installed system, and 
presuming online access to good yum repos, trivially upgrade with one 
command to the type of default system that you would have gotten if you 
had installed from DVD instead of CD.

I.e. I was really peeved that the man-pages rpm did not get installed 
(amonst many other subtle choices made in the name of space fitting). 
But I didn't want to waste time finding out the specific things I really 
wanted, when really I just wanted a "normal system" as defined by the 
choices made for the defaults selected on the non-space-constrained DVD 
spin.

My theory was that you could take the package selections of the spins, 
wrap them in groups, such that with a single yum command, after 
installing from livecd, you could get all the packages that would have 
been installed from the traditional DVD spin.

Likewise, if you got an itch to do ASIC design, and you had just 
installed the normal fedora desktop livecd spin, then you could do 
something like "yum spininstall FedoraElectronicLab".  (spininstall is 
just a random illustration, it could easily enough be wrapped into the 
existing groupinstall command).

</steps off of soapbox for the evening>

-dmc

[Tim Lauridsen]

Douglas McClendon wrote:
>  Tim Lauridsen wrote:
> > Jeroen van Meeuwen wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Here's a thought:
> >>
> >> 1304 random packages will install 724 MB of data in /usr/share/doc
> >>
> >> I'm sure there is /something/ to gain here. If every package on average
> >> installs ~0.5 MB of docs... Would it worth figuring out what docs 
> >> should
> >> be on the LiveCD in the first place? I guess removing everything RPM
> >> calls docs is too much, as this will include man-pages as well.
> >>
> >> Any thoughts?
> >>
> >>   
> > I think it is a bad idea, because many people uses the Live CD's to 
> > install to their systems, and then they end up with a system
> > without doc files, with no easy way to get the docs back on the systems.
>
>  That's really not such a hard thing to fix - the easy way to get 
>  things back after installation. 
>  It also relates to a feature I proposed a long time ago
>
>  "yum spininstall"
>
>  Which would be an easy way to take a livecd installed system, and 
>  presuming online access to good yum repos, trivially upgrade with one 
>  command to the type of default system that you would have gotten if 
>  you had installed from DVD instead of CD.
>
>  I.e. I was really peeved that the man-pages rpm did not get installed 
>  (amonst many other subtle choices made in the name of space fitting). 
>  But I didn't want to waste time finding out the specific things I 
>  really wanted, when really I just wanted a "normal system" as defined 
>  by the choices made for the defaults selected on the 
>  non-space-constrained DVD spin.
>
>  My theory was that you could take the package selections of the spins, 
>  wrap them in groups, such that with a single yum command, after 
>  installing from livecd, you could get all the packages that would have 
>  been installed from the traditional DVD spin.
>
>  Likewise, if you got an itch to do ASIC design, and you had just 
>  installed the normal fedora desktop livecd spin, then you could do 
>  something like "yum spininstall FedoraElectronicLab".  (spininstall is 
>  just a random illustration, it could easily enough be wrapped into the 
>  existing groupinstall command).
>
>  </steps off of soapbox for the evening>
>  
I don't see how you can read the doc without downloading all the rpms 
used to make the livecd and reinstall them.
The LiveCD installer is one of the power features of Fedora 7, i install 
all my systems using the LiveCD's and use yum to add extra stuff after 
the installation. I the doc are removed then all the system is crippled 
and the feature is no longer very useful and that will be a shame.
So if someone creates livecd without docs, they should not be installable.

Tim

[Jeroen van Meeuwen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tim Lauridsen wrote:
>  I don't see how you can read the doc without downloading all the
> rpms
>  used to make the livecd and reinstall them.
>  The LiveCD installer is one of the power features of Fedora 7, i install
>  all my systems using the LiveCD's and use yum to add extra stuff after
>  the installation. 
You could check Revisor and Cobbler as an alternative provisioning system.

 I the doc are removed then all the system is crippled
>  and the feature is no longer very useful and that will be a shame.
>  So if someone creates livecd without docs, they should not be installable.
>   
Whether they should be installable is up to the distributor. This
distributor isn't necessarily the Fedora Project, you know.

Whether the distributor wants 1) the docs or 2) his cool 100MB
multimedia shit, really is up to him. If he chooses to have that result
in a 1) non-installable LiveCD or 2) a crippled system when it is
installed from that same LiveCD, really is up to him. If he wants the
system to be 1) installed and non-crippled from a second medium or 2)
crippled-until the next yum update, so be it.

- --
Kind regards,

Jeroen van Meeuwen
- -kanarip

- --
http://www.kanarip.com/
RHCE, LPIC-2, MCP, CCNA
C6B0 7FB4 43E6 CDDA D258  F70B 28DE 9FDA 9342 BF08
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
>
> iD8DBQFG2Ag4KN6f2pNCvwgRAkUGAJwKqcXYhKmmr8mXf3DUuM0rF0MoJACgmG8j
> mVYDQCxySvzWqtKCbRL915I=
> =Z/Lx
> -----END PGP SIGNATURE-----

[ashok shankar das]

Tim Lauridsen wrote:

>  Jeroen van Meeuwen wrote:
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Here's a thought:
> >
> > 1304 random packages will install 724 MB of data in /usr/share/doc
> >
> > I'm sure there is /something/ to gain here. If every package on average
> > installs ~0.5 MB of docs... Would it worth figuring out what docs should
> > be on the LiveCD in the first place? I guess removing everything RPM
> > calls docs is too much, as this will include man-pages as well.
> >
> > Any thoughts?
> >
> >   
>
>  I think it is a bad idea, because many people uses the Live CD's to 
>  install to their systems, and then they end up with a system 
In my view LiveCD is meant for "on the move OS" It should not be 
installed to a desktop system.
Well there are many ways to put the content of liveCD int ot a desktop 
system.
If a desktop system is needed then a fullblown Fedora should be installed.

>  without doc files, with no easy way to get the docs back on the
> systems.
>
>  Tim
>
>  -- 
>  Fedora-livecd-list mailing list
>  Fedora-livecd-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-livecd-list 


-- 
Thanks
Ashok Shankar Das
RedHat, Pune
[phone]

[Douglas McClendon]

Jeroen van Meeuwen wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>  
>  Here's a thought:
>  
>  1304 random packages will install 724 MB of data in /usr/share/doc
>  
>  I'm sure there is /something/ to gain here. If every package on average
>  installs ~0.5 MB of docs... Would it worth figuring out what docs should
>  be on the LiveCD in the first place? I guess removing everything RPM
>  calls docs is too much, as this will include man-pages as well.
>  
>  Any thoughts? 
Setting asside the redundant fedora-devel changelog thread aspects of 
the discussion...

Back when I was squeezing mandrake-7.2 into a 130MB zisofs-d livecd, 
blindly nuking /usr/share/doc was one of the first things I did (in 
addition to nuking /var/lib/rpm)

But of course there are reasons to want at least parts of both of those 
things.

IMO, the idealistic unrealistic solution (the kind I love talking about 
the most), is to add a couple 'tunables' to the way rpm deals with stuff.

One tunable would be language support.  At the low end, just give me the 
default system language and any other languages I've told the system to 
support.  On the high end, give me all languages available.  In between, 
give me a sliding scale based on language popularity.

The next tunable, would be a generic size one.  On the low end, would be 
the minimal files needed for the minimal functionality of the package. 
On the high end would be every optional extra the package could possibly 
use.  In between again, a sliding scale based on popularity of optional 
component.

Then, you have a yum/rpm command, so that in one fell swoop, you can 
tweak these tunables for all packages in the system.  This would come in 
very handy if you ran into a situation where all of a sudden you needed 
to free up some disk space, or if all of a sudden you increased from a 
40G disk to a 400G disk.  (or if of course you are tuning a livecd 
install for minimal size)

Likewise, during installation, the installer could choose a reasonable 
setting based on the size of the destination volume.

$0.02...

-dmc

[Jeroen van Meeuwen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Douglas McClendon wrote:
>  Jeroen van Meeuwen wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Here's a thought:
> >
> > 1304 random packages will install 724 MB of data in /usr/share/doc
> >
> > I'm sure there is /something/ to gain here. If every package on average
> > installs ~0.5 MB of docs... Would it worth figuring out what docs should
> > be on the LiveCD in the first place? I guess removing everything RPM
> > calls docs is too much, as this will include man-pages as well.
> >
> > Any thoughts?
>  
>  [....]
>  
>  $0.02...
>   
This however does not concern whether we may or may not have unneeded
files on the LiveCD as of *right now*, and if we could possibly delete
those files (manually yet automated) to save space.

We're not talking yum/rpm extensions, we're talking
subprocess.call(["rm","-rf","/usr/share/doc/some/dir"],
		preexecfn=self.run_in_root)

- --
Kind regards,

Jeroen van Meeuwen
- -kanarip

- --
http://www.kanarip.com/
RHCE, LPIC-2, MCP, CCNA
C6B0 7FB4 43E6 CDDA D258  F70B 28DE 9FDA 9342 BF08
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
>
> iD8DBQFG19jVKN6f2pNCvwgRArlMAJ903NlHx3YOJ4xcAK1nVxXPNsgAvwCffb63
> +ldSmTb7t6LlGO+fSBsAkW0=
> =jfrc
> -----END PGP SIGNATURE-----

[Douglas McClendon]

Jeroen van Meeuwen wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>  
>  Douglas McClendon wrote:
> > Jeroen van Meeuwen wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Here's a thought:
> >>
> >> 1304 random packages will install 724 MB of data in /usr/share/doc
> >>
> >> I'm sure there is /something/ to gain here. If every package on average
> >> installs ~0.5 MB of docs... Would it worth figuring out what docs should
> >> be on the LiveCD in the first place? I guess removing everything RPM
> >> calls docs is too much, as this will include man-pages as well.
> >>
> >> Any thoughts?
> > [....]
> >
> > $0.02...
> >
>  
>  This however does not concern whether we may or may not have unneeded
>  files on the LiveCD as of *right now*, and if we could possibly delete
>  those files (manually yet automated) to save space.
>  
>  We're not talking yum/rpm extensions, we're talking
>  subprocess.call(["rm","-rf","/usr/share/doc/some/dir"],
>  		preexecfn=self.run_in_root)
>   
What part of

"
IMO, the idealistic unrealistic solution (the kind I love talking about 
the most)
"

went over your head ;)

-dmc



>  - --
>  Kind regards,
>  
>  Jeroen van Meeuwen
>  - -kanarip
>  
>  - --
>  http://www.kanarip.com/
>  RHCE, LPIC-2, MCP, CCNA
>  C6B0 7FB4 43E6 CDDA D258  F70B 28DE 9FDA 9342 BF08
> >  -----BEGIN PGP SIGNATURE-----
> >  Version: GnuPG v1.4.7 (GNU/Linux)
> >  
> >  iD8DBQFG19jVKN6f2pNCvwgRArlMAJ903NlHx3YOJ4xcAK1nVxXPNsgAvwCffb63
> >  +ldSmTb7t6LlGO+fSBsAkW0=
> >  =jfrc
> >  -----END PGP SIGNATURE----- 
>  
>  --
>  Fedora-livecd-list mailing list
>  Fedora-livecd-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-livecd-list

[Jeroen van Meeuwen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Douglas McClendon wrote:
>  Jeroen van Meeuwen wrote:
>  Douglas McClendon wrote:
> >>> Jeroen van Meeuwen wrote:
> >>>> -----BEGIN PGP SIGNED MESSAGE-----
> >>>> Hash: SHA1
> >>>>
> >>>> Here's a thought:
> >>>>
> >>>> 1304 random packages will install 724 MB of data in /usr/share/doc
> >>>>
> >>>> I'm sure there is /something/ to gain here. If every package on
> average
> >>>> installs ~0.5 MB of docs... Would it worth figuring out what docs
> >>>> should
> >>>> be on the LiveCD in the first place? I guess removing everything RPM
> >>>> calls docs is too much, as this will include man-pages as well.
> >>>>
> >>>> Any thoughts?
> >>> [....]
> >>>
> >>> $0.02...
> >>>
>  
>  This however does not concern whether we may or may not have unneeded
>  files on the LiveCD as of *right now*, and if we could possibly delete
>  those files (manually yet automated) to save space.
>  
>  We're not talking yum/rpm extensions, we're talking
>  subprocess.call(["rm","-rf","/usr/share/doc/some/dir"],
>          preexecfn=self.run_in_root)
>  
>  
> > What part of
>  
> > "
> > IMO, the idealistic unrealistic solution (the kind I love talking about
> > the most)
> > "
>  
> > went over your head ;)
>   
I'm sorry; the OT part.

- --
Kind regards,

Jeroen van Meeuwen
- -kanarip

- --
http://www.kanarip.com/
RHCE, LPIC-2, MCP, CCNA
C6B0 7FB4 43E6 CDDA D258  F70B 28DE 9FDA 9342 BF08
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
>
> iD8DBQFG19uiKN6f2pNCvwgRAsoDAJ0UweOc6w7RUY7bNA1VZ6ZteyTMegCeJnJ5
> NqBbgxb55z11EGuEE9WBI30=
> =QFDT
> -----END PGP SIGNATURE-----

[Jeremy Katz]

On Fri, 2007-08-31 at 10:24 +0200, Jeroen van Meeuwen wrote:
>  Here's a thought:
>  
>  1304 random packages will install 724 MB of data in /usr/share/doc
>  
>  I'm sure there is /something/ to gain here. If every package on average
>  installs ~0.5 MB of docs... Would it worth figuring out what docs should
>  be on the LiveCD in the first place? I guess removing everything RPM
>  calls docs is too much, as this will include man-pages as well.
>  
>  Any thoughts? 
If the live images weren't installable?  Sure.  Since they are, though,
you're trading off a little space in the short-term[1] for hurting every
user in the long-term.  Because they a) won't have the docs if they want
them b) won't be able to use deltarpms[2] c) make the system look hacked
by rpm -V not working, ...

It's really just not a good idea for the official images.  That said,
anyone who wants to for their own unofficial live images that they build
for whatever reason is more than welcome to have "rm
-rf /usr/share/doc/*"[3] in their %post.

The _better_ thing to do is to actually look at what's being installed
as docs and then figure out some improved packaging policy and see about
not shipping some of it.  eg, I'm not sure it makes sense to ship the
ChangeLogs in general, either for the live CD or a regular system.  But
I suspect that to be somewhat controversial.

Jeremy

[1] It was about 10 megs for the end live image the last time I looked.
Which in the scheme of things isn't that much
[2] Because the packages will no longer be intact, you can't recreate
the new package and do a verify.  This will really hurt
[3] Note that you need to be a little bit more careful as this will
remove the default firefox page

[Tim Lauridsen]

Jeremy Katz wrote:
>  On Fri, 2007-08-31 at 10:24 +0200, Jeroen van Meeuwen wrote:
>    
> > Here's a thought:
> >
> > 1304 random packages will install 724 MB of data in /usr/share/doc
> >
> > I'm sure there is /something/ to gain here. If every package on average
> > installs ~0.5 MB of docs... Would it worth figuring out what docs should
> > be on the LiveCD in the first place? I guess removing everything RPM
> > calls docs is too much, as this will include man-pages as well.
> >
> > Any thoughts?
> >     
>
>  If the live images weren't installable?  Sure.  Since they are, though,
>  you're trading off a little space in the short-term[1] for hurting every
>  user in the long-term.  Because they a) won't have the docs if they want
>  them b) won't be able to use deltarpms[2] c) make the system look hacked
>  by rpm -V not working, ...
>
>  It's really just not a good idea for the official images.  That said,
>  anyone who wants to for their own unofficial live images that they build
>  for whatever reason is more than welcome to have "rm
>  -rf /usr/share/doc/*"[3] in their %post.
>
>  The _better_ thing to do is to actually look at what's being installed
>  as docs and then figure out some improved packaging policy and see about
>  not shipping some of it.  eg, I'm not sure it makes sense to ship the
>  ChangeLogs in general, either for the live CD or a regular system.  But
>  I suspect that to be somewhat controversial.
>
>  Jeremy
>
>  [1] It was about 10 megs for the end live image the last time I looked.
>  Which in the scheme of things isn't that much
>  [2] Because the packages will no longer be intact, you can't recreate
>  the new package and do a verify.  This will really hurt
>  [3] Note that you need to be a little bit more careful as this will
>  remove the default firefox page
>
>  --
>  Fedora-livecd-list mailing list
>  Fedora-livecd-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-livecd-list
>     
+ 1000

Tim

[Jeroen van Meeuwen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeremy Katz wrote:
>  On Fri, 2007-08-31 at 10:24 +0200, Jeroen van Meeuwen wrote:
> > Here's a thought:
> >
> > 1304 random packages will install 724 MB of data in /usr/share/doc
> >
> > I'm sure there is /something/ to gain here. If every package on average
> > installs ~0.5 MB of docs... Would it worth figuring out what docs should
> > be on the LiveCD in the first place? I guess removing everything RPM
> > calls docs is too much, as this will include man-pages as well.
> >
> > Any thoughts?
>  
>  If the live images weren't installable?  Sure.  Since they are, though,
>  you're trading off a little space in the short-term[1] for hurting every
>  user in the long-term.  Because they a) won't have the docs if they want
>  them b) won't be able to use deltarpms[2] c) make the system look hacked
>  by rpm -V not working, ...
>   
Ohw, but my thoughts do not necessarily apply only to what the Fedora
Project wants/needs. I'm with you that this should not be applied to
LiveCDs the Fedora Project distributes and have a default to copy
themselves block-by-block. For other LiveCDs however, distributed along
with some medium carrying RPMs or using a netinstall tree or simply not
being installable removing any irrelevant files is a space-saver, don't
you think?

>  It's really just not a good idea for the official images.  That
> said,
>  anyone who wants to for their own unofficial live images that they build
>  for whatever reason is more than welcome to have "rm
>  -rf /usr/share/doc/*"[3] in their %post.
>   
I was looking for a way to be more considerate with removing files ;-)
That's actually what the thread was about in the first place.

>  The _better_ thing to do is to actually look at what's being
> installed
>  as docs and then figure out some improved packaging policy and see about
>  not shipping some of it.  eg, I'm not sure it makes sense to ship the
>  ChangeLogs in general, either for the live CD or a regular system.  But
>  I suspect that to be somewhat controversial.
>   
You're right this is what I wanted in the first place. If I think of a
LiveCD I think of a fully-featured desktop more then a fully-documented
command shell because the CD has only 700MB. I'm looking for what can be
removed without loosing common help documentation, but getting rid of
files that consume space I could maybe use to put an extra feature in.
If this disables being rpm -qVa'd, so be it. If it's not installable, so
be it. If I need some extra medium carrying the RPMs or need to go
online, so be it. A LiveCD IMO is often just a show-case, not an
installer nor a system that runs for hours and hours and needs to be rpm
- -qV(a)'d from time to time.

>  Jeremy
>  
>  [1] It was about 10 megs for the end live image the last time I looked.
>  Which in the scheme of things isn't that much 
Just the ChangeLogs? 10 megs? Wow.

- --
Kind regards,

Jeroen van Meeuwen
- -kanarip

- --
http://www.kanarip.com/
RHCE, LPIC-2, MCP, CCNA
C6B0 7FB4 43E6 CDDA D258  F70B 28DE 9FDA 9342 BF08
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
>
> iD8DBQFG2AwUKN6f2pNCvwgRAsqMAJ0Zli9GAn3bIy5b0yDeAH04B/PaWgCgn6oU
> M7lOC1fqHbB5G69ZnlVlP8M=
> =uRPJ
> -----END PGP SIGNATURE-----

[Douglas McClendon]

Jeremy Katz wrote:
>  On Fri, 2007-08-31 at 10:24 +0200, Jeroen van Meeuwen wrote:
> > Here's a thought:
> >
> > 1304 random packages will install 724 MB of data in /usr/share/doc
> >
> > I'm sure there is /something/ to gain here. If every package on average
> > installs ~0.5 MB of docs... Would it worth figuring out what docs should
> > be on the LiveCD in the first place? I guess removing everything RPM
> > calls docs is too much, as this will include man-pages as well.
> >
> > Any thoughts?
>  
>  If the live images weren't installable?  Sure.  Since they are, though,
>  you're trading off a little space in the short-term[1] for hurting every
>  user in the long-term.  Because they a) won't have the docs if they want
>  them b) won't be able to use deltarpms[2] c) make the system look hacked
>  by rpm -V not working, ... 
preface: I'm not arguing for doing this sort of thing in F8 or F9 even.

But as mentioned, creating a post install tool that with one 
button/commandline fetches all the missing stuff is trivial.  After 
which deltarpms works.  And for (c), rpm -V will work, it will just show 
missing files.  Out of curiosity, can you provide me an example where if 
I did rpm -V on all the rpms of my system, and all I saw was missing 
files, that I should be worried about my system being hacked?  I just 
honestly am curious.  (I'm guessing that I could come up with an example 
if I really thought about it, but nothing springs to mind immediately).


>  
>  It's really just not a good idea for the official images.  That said,
>  anyone who wants to for their own unofficial live images that they build
>  for whatever reason is more than welcome to have "rm
>  -rf /usr/share/doc/*"[3] in their %post.
>  
>  The _better_ thing to do is to actually look at what's being installed
>  as docs and then figure out some improved packaging policy and see about
>  not shipping some of it.  eg, I'm not sure it makes sense to ship the
>  ChangeLogs in general, either for the live CD or a regular system.  But
>  I suspect that to be somewhat controversial. 
I think it is only controversial for the precise reason we are debating 
it.  I.e. in any system that isn't constrained to 700MB, you really 
ought to go ahead and throw the full changelogs in, because the 
cost/benefit in that situation dictates that choice.  Whereas in the 
livecd case, the cost/benefit dictates the opposite choice.

-dmc

[Matthias Clasen]

On Fri, 2007-08-31 at 10:24 +0200, Jeroen van Meeuwen wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>  
>  Here's a thought:
>  
>  1304 random packages will install 724 MB of data in /usr/share/doc
>  
>  I'm sure there is /something/ to gain here. If every package on average
>  installs ~0.5 MB of docs... Would it worth figuring out what docs should
>  be on the LiveCD in the first place? I guess removing everything RPM
>  calls docs is too much, as this will include man-pages as well.
>  
>  Any thoughts?
>   
As long as you are willing to ignore the rpm verification issue that
gets raised every time this is mentioned (or go with Douglas'
fixup-script approach), dropping language support is certainly going to
give you just as much if not more space savings. 

I recently added %lang tags to most of the big gnome help documents
documents in /usr/share/gnome/help. Also, dropping CJK fonts easily
saves some 40M.


Matthias

[Douglas McClendon]

Matthias Clasen wrote:
>  On Fri, 2007-08-31 at 10:24 +0200, Jeroen van Meeuwen wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Here's a thought:
> >
> > 1304 random packages will install 724 MB of data in /usr/share/doc
> >
> > I'm sure there is /something/ to gain here. If every package on average
> > installs ~0.5 MB of docs... Would it worth figuring out what docs should
> > be on the LiveCD in the first place? I guess removing everything RPM
> > calls docs is too much, as this will include man-pages as well.
> >
> > Any thoughts?
> >
>  
>  As long as you are willing to ignore the rpm verification issue that
>  gets raised every time this is mentioned (or go with Douglas'
>  fixup-script approach),  

Also, it occurred to me that the more complete solution to the rpm 
verification issue would be to have a (signed?) list of files that are 
expected to be missing.  Then with either a wrapper, or a minor mod to 
rpm, you could have just as complete verification.

Then, the solution to the inefficient fixup problem (downloading whole 
rpms just to get the small missing files), if one were serious about it, 
you could obviously for every shipped livecd, create a single signed 
package of just the missing files.


dropping language support is certainly going to
>  give you just as much if not more space savings. 
>  
>  I recently added %lang tags to most of the big gnome help documents
>  documents in /usr/share/gnome/help. Also, dropping CJK fonts easily
>  saves some 40M. 
Yup, languages and fonts I can't read gets me emacs, thunderbird, and 
openoffice :)

Then of course there is the good ol SELinux...  For those multitude of 
situations when the cost benefit equation suggests forgoing the ~7% 
performance and ~7% cdrom space hit.  (though I truly welcome any 
verbose response explaining lots of examples of how SELinux protects me 
when I'm just web browsing from a desktop with no exposed ports/services)

-dmc

[Patrice Guay]

Douglas McClendon a écrit :
>  Matthias Clasen wrote:
> > On Fri, 2007-08-31 at 10:24 +0200, Jeroen van Meeuwen wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Here's a thought:
> >>
> >> 1304 random packages will install 724 MB of data in /usr/share/doc
> >>
> >> I'm sure there is /something/ to gain here. If every package on average
> >> installs ~0.5 MB of docs... Would it worth figuring out what docs
> >> should
> >> be on the LiveCD in the first place? I guess removing everything RPM
> >> calls docs is too much, as this will include man-pages as well.
> >>
> >> Any thoughts?
> >>
> >
> > As long as you are willing to ignore the rpm verification issue that
> > gets raised every time this is mentioned (or go with Douglas'
> > fixup-script approach), 
>
>  Also, it occurred to me that the more complete solution to the rpm
>  verification issue would be to have a (signed?) list of files that are
>  expected to be missing.  Then with either a wrapper, or a minor mod to
>  rpm, you could have just as complete verification.
>
>  Then, the solution to the inefficient fixup problem (downloading whole
>  rpms just to get the small missing files), if one were serious about
>  it, you could obviously for every shipped livecd, create a single
>  signed package of just the missing files.
>
>  
If this package is shipped as a RPM, conflict may arise with the
original RPM about file ownership.
 
> > dropping language support is certainly going to give you just as
> much
> > if not
> > more space savings. I recently added %lang tags to most of the big
> > gnome help
> > documents in /usr/share/gnome/help. Also, dropping CJK fonts easily
> > saves some 40M. 
On my current live CD release, I strip rarely used
documentation files
(changelog, news, non-englist html files). This saves 7MB on the
resulting Live CD. I also remove language files and it saves 95MB of
compressed space.

--
Patrice

[Jon Steer]

I'd be interested in the "-" lines that you use to strip the files out.

As the generator of a console-based server distribution I am
interested in losing as many extraneous packages as possible.

For me, stripping down the size of the ISO has more to do with space
considerations for either USB-based distributions or when I'm booting
the LiveCD into a VM and I'd like to save real memory space.

jon


On 8/31/07, Patrice Guay <patrice.guay(a)nanotechnologies.qc.ca&gt; wrote:
>  Douglas McClendon a écrit :
>  > Matthias Clasen wrote:
>  >> On Fri, 2007-08-31 at 10:24 +0200, Jeroen van Meeuwen wrote:
>  >>> -----BEGIN PGP SIGNED MESSAGE-----
>  >>> Hash: SHA1
>  >>>
>  >>> Here's a thought:
>  >>>
>  >>> 1304 random packages will install 724 MB of data in /usr/share/doc
>  >>>
>  >>> I'm sure there is /something/ to gain here. If every package on average
>  >>> installs ~0.5 MB of docs... Would it worth figuring out what docs
>  >>> should
>  >>> be on the LiveCD in the first place? I guess removing everything RPM
>  >>> calls docs is too much, as this will include man-pages as well.
>  >>>
>  >>> Any thoughts?
>  >>>
>  >>
>  >> As long as you are willing to ignore the rpm verification issue that
>  >> gets raised every time this is mentioned (or go with Douglas'
>  >> fixup-script approach),
>  >
>  > Also, it occurred to me that the more complete solution to the rpm
>  > verification issue would be to have a (signed?) list of files that are
>  > expected to be missing.  Then with either a wrapper, or a minor mod to
>  > rpm, you could have just as complete verification.
>  >
>  > Then, the solution to the inefficient fixup problem (downloading whole
>  > rpms just to get the small missing files), if one were serious about
>  > it, you could obviously for every shipped livecd, create a single
>  > signed package of just the missing files.
>  >
>  >
>  If this package is shipped as a RPM, conflict may arise with the
>  original RPM about file ownership.
>
>  >> dropping language support is certainly going to give you just as much
>  >> if not
>  >> more space savings. I recently added %lang tags to most of the big
>  >> gnome help
>  >> documents in /usr/share/gnome/help. Also, dropping CJK fonts easily
>  >> saves some 40M.
>  On my current live CD release, I strip rarely used documentation files
>  (changelog, news, non-englist html files). This saves 7MB on the
>  resulting Live CD. I also remove language files and it saves 95MB of
>  compressed space.
>
>  --
>  Patrice
>
>  --
>  Fedora-livecd-list mailing list
>  Fedora-livecd-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-livecd-list
>  

-- 

"Whereever you go, there you are"

[Patrice Guay]

Jon Steer wrote:
>  I'd be interested in the "-" lines that you use to
> strip the files out.
>
>  As the generator of a console-based server distribution I am
>  interested in losing as many extraneous packages as possible.
>
>  For me, stripping down the size of the ISO has more to do with space
>  considerations for either USB-based distributions or when I'm booting
>  the LiveCD into a VM and I'd like to save real memory space.
http://www.nanotechnologies.qc.ca/propos/linux/centos-live/i386/live/cent...

--
Patrice

[Rahul Sundaram]

Douglas McClendon wrote:
>  
>  Then of course there is the good ol SELinux...  For those multitude of 
>  situations when the cost benefit equation suggests forgoing the ~7% 
>  performance and ~7% cdrom space hit.  (though I truly welcome any 
>  verbose response explaining lots of examples of how SELinux protects me 
>  when I'm just web browsing from a desktop with no exposed ports/services) 
There is no recent benchmarking done on what the performance cost is and 
it is likely to vary widely depending on how you use it. Fedora 7 has 
SELinux profiles for browsers too limiting the amount of damage in any 
exploit.

Rahul