FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 07-15-2011, 11:31 PM
Arno Töll
 
Default How Debian Deals with Data

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Christopher,

On 16.07.2011 00:20, Christopher Baines wrote:
> The actual package would just contain the rules and checksums for the
> files it tries to fetch, but not the data itself, I think of this as a
> symbolic package. This approach in my opinion, would make packaging
> applications like FlightGear much easier, and improve the user
> experience.

just as a random alternative idea (where other people may judge whether
it is a good idea or not): There might still be benefits of letting dpkg
handle the installation stuff, even if you don't want to have such a
large amount of data in the archives.

This eases maintenance, updates and clean removal of packages. For your
purpose it might be worth to consider a half baked solution. For example
you could provide a meta package[*] which builds a new binary package
on the installation site. Without knowing anything about FlightGear this
potentially seems a good solution to me. Your meta package could
download your stuff, apply some checksumming and then produce a new
binary package with the actual game data.

Take a look into the google-earth package for an example what I'm
thinking about. Their use case is of course different than yours, but
the idea is the same.

This binary package may ease installation, transportation and copying of
your game's data. By using some nifty dependencies along with
"Provides"/"Replaces" relationships you could even do some interesting
dependency magic there, although the direct usage of "dpkg" makes it a
bit tricky to benefit from it.
[*] please don't confuse my usage of "meta package" with its
archive-wide meaning for Debian here.


- --
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOIM3IAAoJEMcrUe6dgPNtdyEQAK3VVNWigu TMvlFl9JW6Mnua
CBTFSDiBAw6Fbhtd4HKqGAe1nRrEkiMtczHnDjOUIKGI7+S9Z+ M7nFAkRayz/KLr
FMCKxAFuvshxAbNQTUHob6IXk9R/9ZRzRpbMVDiGpkWHSM+I7Mq3PAU2Ix4F+1+j
D2JuCUSne9bpuxlFnf/xXZyMkBrHC99EWfoSg+okRI9V9lhVUurf1+bVosMDmium
R5v8KktpmFyYSQ9Ik00QAItUxJOkExNAvfdZ+l9bTU5KIGI/lfjOXAbbfASYJ7cL
TazM8TNeRadTqtWTC9KkhmplGLYBinNAZzcEPy0fSfGQdOd0u1 2dMwg1+Pqtmbfa
/ivqfRxxlP7mCTXBcq+97Kadh/44Ei3uzxdQ9BQ/ZNj5Po0mCvx6PValrRzRHmaf
+DVJhQdBec1ij+H0ouUdw+wzVRgUkL6RWz790jQ1xVB1wrKtwN nSaUiWGM3bQY/L
8eT/JiphCQvVx1ewaefA0q7pzYGT/ZlZ39TEMxtvfiHU+HPpLCPFUlmP8snp1/i+
lNOUwh+jdCQ2OOPt++LERq3a6ubuPtJWlYxEXOL2DZsNsiGRx1 2mG9hi2eZlGiAJ
emOp4PtuF1KNdSg/0Fl5sM1MeJk5FC1BKMf5+LgM27G2mrSKBcwWvqCvFXXofSBj
WB4Gbvo5RiH/EFIK6mve
=Q03t
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4E20CDC9.2080601@toell.net">http://lists.debian.org/4E20CDC9.2080601@toell.net
 
Old 07-16-2011, 10:06 AM
Christopher Baines
 
Default How Debian Deals with Data

On Sat, 2011-07-16 at 01:31 +0200, Arno Töll wrote:
> Hi Christopher,
>
> On 16.07.2011 00:20, Christopher Baines wrote:
> > The actual package would just contain the rules and checksums for the
> > files it tries to fetch, but not the data itself, I think of this as a
> > symbolic package. This approach in my opinion, would make packaging
> > applications like FlightGear much easier, and improve the user
> > experience.
>
> just as a random alternative idea (where other people may judge whether
> it is a good idea or not): There might still be benefits of letting dpkg
> handle the installation stuff, even if you don't want to have such a
> large amount of data in the archives.
>
> This eases maintenance, updates and clean removal of packages. For your
> purpose it might be worth to consider a half baked solution. For example
> you could provide a meta package[*] which builds a new binary package
> on the installation site. Without knowing anything about FlightGear this
> potentially seems a good solution to me. Your meta package could
> download your stuff, apply some checksumming and then produce a new
> binary package with the actual game data.
>
> Take a look into the google-earth package for an example what I'm
> thinking about. Their use case is of course different than yours, but
> the idea is the same.
>
> This binary package may ease installation, transportation and copying of
> your game's data. By using some nifty dependencies along with
> "Provides"/"Replaces" relationships you could even do some interesting
> dependency magic there, although the direct usage of "dpkg" makes it a
> bit tricky to benefit from it.
>
>[*] please don't confuse my usage of "meta package" with its
> archive-wide meaning for Debian here.

I would consider the best solution to be a mixture of the two, so the
symbolic package handles fetching the data, but then tells dpkg what
files its putting where. I definitely think that it would be useful to
be able to take a symbolic package, and turn it in to a normal package,
but if you don’t want the package, just the stuff on your system, there
should just be a way skip out the package (this is mainly for space,
because if someone has just enough room for the actual installation, you
don’t want to waste space giving them a package as well.

Chris
 
Old 07-16-2011, 10:20 AM
Christopher Baines
 
Default How Debian Deals with Data

On Fri, 2011-07-15 at 22:32 +0000, The Fungi wrote:
> On Fri, Jul 15, 2011 at 11:20:09PM +0100, Christopher Baines wrote:
> [...]
> > Any thoughts, or have I found a non-existent problem?
>
> A very-existent problem (the scientific package maintainers deal
> with this at least as much as the games package maintainers from
> what I gather). It's come up a lot over the years, but the most
> recent productive thread I remember was this one about a
> data.debian.org archive proposal for extremely large,
> architecture-independent data packages:
>
> http://lists.debian.org/debian-devel/2010/09/msg00692.html
>
> I'm not sure what became of that, but I'm curious to find out since
> I'll be staring down the barrel of a similar problem soon enough.

A specific package repository for data packages would help the
situation, but its not very flexible? Most of this data is already
available on the internet, why not allow the user to either fetch it
from there, or from other installation media they might have?

Chris
 
Old 07-16-2011, 12:02 PM
Simon McVittie
 
Default How Debian Deals with Data

On Sat, 16 Jul 2011 at 01:31:21 +0200, Arno Töll wrote:
> On 16.07.2011 00:20, Christopher Baines wrote:
> > The actual package would just contain the rules and checksums for the
> > files it tries to fetch, but not the data itself
>
> just as a random alternative idea (where other people may judge whether
> it is a good idea or not): There might still be benefits of letting dpkg
> handle the installation stuff, even if you don't want to have such a
> large amount of data in the archives.

It might be worth comparing the old quake2-data (see snapshot.debian.org) with
game-data-packager's use to produce quake3-data etc. - the former behaves
as Christopher suggested, the latter behaves as Arno suggested.

(This is mainly for legal reasons - the data files are proprietary and must
not be distributed - but if they were non-free-but-distributable we might
still want to use g-d-p for size reasons.)

I noticed the other day that Ubuntu still has an old copy of quake3-data from
pkg-games svn, which behaves like quake2-data used to. I should probably
ask them to remove it, since they also have game-data-packager...

S


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110716120243.GA23596@reptile.pseudorandom.co.uk" >http://lists.debian.org/20110716120243.GA23596@reptile.pseudorandom.co.uk
 
Old 07-16-2011, 12:02 PM
Simon McVittie
 
Default How Debian Deals with Data

On Sat, 16 Jul 2011 at 01:31:21 +0200, Arno Töll wrote:
> On 16.07.2011 00:20, Christopher Baines wrote:
> > The actual package would just contain the rules and checksums for the
> > files it tries to fetch, but not the data itself
>
> just as a random alternative idea (where other people may judge whether
> it is a good idea or not): There might still be benefits of letting dpkg
> handle the installation stuff, even if you don't want to have such a
> large amount of data in the archives.

It might be worth comparing the old quake2-data (see snapshot.debian.org) with
game-data-packager's use to produce quake3-data etc. - the former behaves
as Christopher suggested, the latter behaves as Arno suggested.

(This is mainly for legal reasons - the data files are proprietary and must
not be distributed - but if they were non-free-but-distributable we might
still want to use g-d-p for size reasons.)

I noticed the other day that Ubuntu still has an old copy of quake3-data from
pkg-games svn, which behaves like quake2-data used to. I should probably
ask them to remove it, since they also have game-data-packager...

S


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110716120243.GA23596@reptile.pseudorandom.co.uk" >http://lists.debian.org/20110716120243.GA23596@reptile.pseudorandom.co.uk
 

Thread Tools




All times are GMT. The time now is 07:03 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org