a simple question: why unpack RPMS? Clearly Linux itself can be run compressed (Live CDs do that now). Given the bottleneck of slow disk and fast CPU it might be faster to load the compressed image, unpack it, and execute it then it would to load it directly. Yet another feature is that RPMS don't have to explode all over the filesystem so upgrading is just a copy operation. Is anyone aware of an effort to make an RPM filesystem? Could such a filesystem run in user space?
RPMS might not be the very best format for compressed packages but they could make a convenient starting point. Fedora extras would be so much sweeter if you only needed to mount the DVD containing the RPMS and it all "just worked".
Tim Daly axiom@tenkan.org daly@idsi.net
On Thu, Jun 03, 2004 at 10:31:51AM -0400, Tim Daly wrote:
RPMS might not be the very best format for compressed packages but they could make a convenient starting point. Fedora extras would be so much sweeter if you only needed to mount the DVD containing the RPMS and it all "just worked".
Interesting idea... but at leat the pre/post-install scripts, that are needed in many cases (e.g. ldconfig) cause significant problems if you would implement such a beast.
Le jeu, 03/06/2004 à 10:31 -0400, Tim Daly a écrit :
a simple question: why unpack RPMS? Clearly Linux itself can be run compressed (Live CDs do that now). Given the bottleneck of slow disk and fast CPU it might be faster to load the compressed image, unpack it, and execute it then it would to load it directly.
Because there are those pesky thinks known as configuration files that *will* be modified post-install and people don't want to hunt for into a gazillon archives, because it permits interoperability with all sorts of differently packaged software, because one often does not use 100% of a package at a time (thus the overhead of loading the whole archive in memory would be *huge*), etc, etc
Sun tried to go the sinle-archive way with war files. The first thing the reference java application server (tomcat) does with them is to unpack them to disk. So you waste disk space, cpu time, get all the problems of closed archives without any real benefit.
Seems proprietary vendors like them however. They feel it saves them the bother of actually having to follow the system standards to interoperate correctly, since most humans won't check the junk they stuff their archives with (see also security through obscurity)
On 2004-06-03 (Thursday) 17:31, Tim Daly wrote:
a simple question: why unpack RPMS? Clearly Linux itself can be run compressed (Live CDs do that now). Given the bottleneck of slow disk
Live CDs based on konppix do use compressed ISO image, which is a FS, the compression comes from the cloop kernel module (compressed loop) which transparently makes it look like an usual block device.
and fast CPU it might be faster to load the compressed image, unpack it, and execute it then it would to load it directly. Yet another feature is that RPMS don't have to explode all over the filesystem so upgrading is just a copy operation. Is anyone aware of an effort
You'll have to mount somehow them. What will it look like to have say 500-1000 'mounted' packages?
to make an RPM filesystem? Could such a filesystem run in user space?
RPMS might not be the very best format for compressed packages but they could make a convenient starting point. Fedora extras would be so much sweeter if you only needed to mount the DVD containing the RPMS and it all "just worked".
Tim Daly axiom@tenkan.org daly@idsi.net
There are other things that are designed and convenient for this purpose like cloop. Even if the problem with the configuration files and /log and even /var is solved, it is still too inconvenient to unpack the whole archive just to read the file that's on it's end. If I understand the compression right, there's no way to start decompressing a rpm package from the middle. AFAIK rpm is gzipped cpio archive with headers, check the script at http://www.rpm.org/tools/scripts/rpm2cpio.sh if you care. Your idea could work if each file was individually compressed, which will not be advisable for rpm because this will lower the compression ratio. I was thinking of something opposite one day - what about if the first fedora CD is a cloop image like knoppix and all rpm packages can be 'restored' from it and directly installed on the disk? The main problem I see is that the GPG sign of a rpm package is calculated from it's compressed image (please correct me if I'm wrong). No one can guarantee that when recreated from the installed files and compressed the GPG sign will match it any more. If the sign is calculated from it's uncompressed image this could work... I don't say this is not possible, I just think it's inadvisable.
I'll ask someone more familiar with the rpm package format to correct me if I'm wrong at some point.
On Thu, 03 Jun 2004 10:31:51 -0400, Tim Daly wrote:
a simple question: why unpack RPMS? Clearly Linux itself can be run compressed (Live CDs do that now). Given the bottleneck of slow disk and fast CPU it might be faster to load the compressed image, unpack it, and execute it then it would to load it directly.
This is true on CD drives which are very slow compared to hard disks, but I think it would hurt performance for hard disk installs. Besides raw transfer speed is not normally the problem with loading things from hard disks, it's thinks like seek time+rotational latency.
thanks -mike
On Thu, 2004-06-03 at 07:31, Tim Daly wrote:
a simple question: why unpack RPMS? Clearly Linux itself can be run compressed (Live CDs do that now). Given the bottleneck of slow disk and fast CPU it might be faster to load the compressed image, unpack it, and execute it then it would to load it directly.
Just use a normal compressed filesystem if you're worried by disk usage.
Yet another feature is that RPMS don't have to explode all over the filesystem so upgrading is just a copy operation.
That feature becomes a bug when files belonging to packages need to be modified as part of normal functioning (see /etc).
-
Doncho N. Gunchev -
Florin Andrei -
Jos Vos -
Mike Hearn -
Nicolas Mailhot -
Tim Daly