Mailinglist Archive: opensuse-packaging (183 mails)

< Previous Next >
Re: [opensuse-packaging] Packaging big files
  • From: Cristian Morales Vega <cmorve69@xxxxxxxx>
  • Date: Thu, 25 Jun 2009 19:12:17 +0200
  • Message-id: <8235e6f40906251012g407531d5sf0691a75f25b1e43@xxxxxxxxxxxxxx>
2009/6/25 Peter Poeml <poeml@xxxxxxx>:
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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-packaging+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups