RPM roadmapping

[Douglas McClendon]

Peter Jones wrote:
> Ralf Ertzinger wrote:
>> Hi.
>>
>> On Thu, 02 Aug 2007 16:53:43 +0300, Jonathan Dieter wrote:
>>
>>> The main problem with using cpio is that individual files have a limit
>>> of 2GB (which isn't a problem in most cases, but it is a limit).  Why
>>> not push a newer cpio format that changes all 16-bit and 32-bit
>>> records to 64-bit (along with specifying endienness)?
>>
>> What exactly is the use case of files larger than 2GB wrt RPM?
> 
> Believe it or not, I know of one piece of software with a 3GB (compiled) 
> regular expression automaton.  Though it'll never be a candidate for a 
> package in Fedora, it'd still be nice if the vendor could package it in 
> rpm.  The same is true for large datasets.

I could see this being useful at some point in the future with something like 
nasa whirlwind and large sat imagery databases.  Currently I suspect such users 
of massive datasets are quite happy managing their own multi terabyte 
collections of various data provided from various sources.  But I suppose if you 
keep in mind the 1.44MB floppy -> $10 1GB microsd-usb path, you also should keep 
in mind that we aren't so far away from a 10T laptop, perhaps holding 1T of 
public sat imagery displayable via whirlwind, just because it's cool and free. 
(except for cheney's house of course).  And probably by that time, if possible, 
people would enjoy managing their various sat imagery layers with the same 
package management tool as the rest of their system.

And of course then their are video games with datasets that large, or perhaps 
just depending on the ubiquitous free nasa whirlwind datasets.

But of course then someone will make a video game that simulates terrorism, or 
even global thermonuclear war, and the feds will have to crack down on this new 
'virtual terrorism training ground' ;)

-dmc

> Frankly, it's useful for all the same reasons as having support for >2GB 
> files *at all* in the OS.