-----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
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
-----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
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
-----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
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
-----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
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@redhat.com [mailto:fedora-livecd-list-bounces@redhat.com] On Behalf Of Jeroen van Meeuwen Sent: Friday, August 31, 2007 4:56 AM To: fedora-livecd-list@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
-- Fedora-livecd-list mailing list Fedora-livecd-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-livecd-list
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@redhat.com [mailto:fedora-livecd-list-bounces@redhat.com] On Behalf Of Mohammed_Khan@Dell.com Sent: Friday, August 31, 2007 11:03 AM To: fedora-livecd-list@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@redhat.com [mailto:fedora-livecd-list-bounces@redhat.com] On Behalf Of Jeroen van Meeuwen Sent: Friday, August 31, 2007 4:56 AM To: fedora-livecd-list@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
-- Fedora-livecd-list mailing list Fedora-livecd-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-livecd-list
-- Fedora-livecd-list mailing list Fedora-livecd-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-livecd-list
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
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@redhat.com [mailto:fedora-livecd-list-bounces@redhat.com] On Behalf Of Jeremy Katz Sent: Tuesday, October 02, 2007 4:04 PM To: fedora-livecd-list@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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-livecd-list
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
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@redhat.com [mailto:fedora-livecd-list-bounces@redhat.com] On Behalf Of Jeremy Katz Sent: Tuesday, October 02, 2007 5:25 PM To: fedora-livecd-list@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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-livecd-list
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
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
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
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
-----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
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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-livecd-list
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
-----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
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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-livecd-list
-----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
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
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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-livecd-list
+ 1000
Tim
-----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
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
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
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
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
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@nanotechnologies.qc.ca 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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-livecd-list
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/centos-...
-- Patrice
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
livecd@lists.fedoraproject.org