2009/6/25 Peter Poeml
Hi,
On Tue, Jun 09, 2009 at 08:49:40 +0200, Cristian Morales Vega wrote:
What is the best way to package big/redistribution restricted files? Packman seems to use http://sourceforge.net/projects/autodownloader, but it has the problem that it isn't integrated with RPM. From an user POV you still get updates automatically, but you can't use rpm -V to check the installation integrity.
There is anything better? Any plan for repositories with metadata that point to BitTorrent packages? A patched rpmbuild that adds the RPM headers for unpackaged files that get downloaded in a %pre scriptlet? In the worst case... from a quick look I didn't saw anything, but there is any library to easily access to the RPM DB so I could patch autodownloader? addFile(package, file_path)?
You could package the big files somewhere else (separate build service instance), and have users subscribe to the repository. That way, the space would be used on a different system than ours and we wouldn't be bothered.
You could also provide the large files (in unpackaged form) elsewhere, and have them downloaded via %post scriptlets. If there's mirroring, you could create metalinks and use aria2c for downloading, which takes care of content verification and mirror load balancing. (You could package the metalink into your buildservice package as well.)
The files are already hosted in a lot of places, so it's a shame not to use them. But I would like a way that after installation there is no difference from a real RPM with the files packaged. I could put %ghost file entries and download the real files in a scriplet (or autodownloader, as Packman does)... but that would be still not the same. I know everything about these files, hash included, so I would like a way that puts that info into the RPM DB. Something that would list all the correct info when I do a "rpm -qvl" or a "rpm -V".
...and, we have any official "limit" to the file size of a package? When it's a problem for mirrors?
Well, everything which contributes to size contributes to the problem. Which size are you talking about, roughly? If we know what you are up to, we can deal with it for instance by excluding files from ending up on the "normal" mirrors, and instead mirroring them elsewhere. Depending on the popularity, it'll be worthwhile to go this path. Popular content deserves to be mirrored, so widespread mirroring *might* make sense. In contrast, if the content is hardly used then it's good to make sure it won't end up on too many mirrors (resulting only in waste of space and bandwidth).
Feel free to contact me with details.
Thanks for your considerate post!
I though about this when I saw FreeSpace 2. The enhanced game contect is already 1,4 GiB uncompressed (perhaps 1 GiB compressed). Add 900 MiB for the FreeSpace 1 port... and even 250 MiB more for cutscenes. That's without thinking about other MODs. For this specific case I'm not really thinking about putting all this in the OBS, but made me think about the problem. But the big data content is an increasing problem with games. A more real example would be Warzone 2100, since 2.2 version it added support for videos... 162 MiB. That's a number that makes one wonder if it's ok, needs any special care or what. Do you have any stats for the downloads of the previous versions of the game? If isn't very popular perhaps a README.openSUSE saying that the user can download the videos file and put it in his home dir would be enough. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org