[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Checklist for packaging games



On Sun, Apr 20, 2008 at 08:23:22PM +0200, Vincent Fourmond wrote:
> Andres Mejia wrote:
> >>  * Game data is packaged in a separated arch indep (all) package if it's
> >> big enough
> >>
> >>  * Game data is in a separate source package if it is large
> > 
> > Depends on what's defined as "large". Is it >50MB? >650MB? etc.
> 
>   I guess game data deserves a separated Arch: all package if it is
> bigger than 1 MB (maybe even smaller). Don't forget that for a full
> mirror, a Arch: any package is weighting (currently) twelve times bigger
> than an Arch: all one...

Yes, but that's the first point ("if it's big enough").  I think the
comment was about the second one ("if it's large").  What is the good
thing about a separate source package, if upstream releases it as one
tarball?  That people hacking the game don't need to download the data
source?  That makes sense, but only if it gets really really big.  It
adds extra administration for us, and isn't useful for most people (who
either don't download the source, or have a fast connection).  For
mirrors, a separate source package doesn't really make a difference
either (compared to a separate binary package from the same source).

Also, with a separate source package there are problems with
dependencies.  If you have one source package, you can just use
(= ${source:version}).  Then the packager has tested it with this
combination, and things should just work.  With two packages, you will
need to track if the data doesn't start changing format, or something
like that.

And by the way, congratulations to all new DDs around here. :-D

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html

Attachment: signature.asc
Description: Digital signature


Reply to: