Hi,
The problem here is that in order to be really free (in the Debian
sense) the .tar.gz provided on Debian mirrors should be self-contained:
xmoto's CVS could vanish away, and still users should be able to modify
xmoto, including graphics and other data provided in xmoto.bin. Or we
could even want to patch the source to replace strawberries with the
nice Debian swirl (it's just an example, I won't do that ;).
Of course, providing the images (etc) both in png format (for example)
and in xmoto.bin in the .tar.gz would be a waste of space. I think that
the easiest way to fix this problem would be to provide a "xmoto-edit
-unpack" which would extract the data from xmoto.bin such that we could
do a xmoto-edit -pack on the generated files. Alternatively, only png
(etc) could be shipped in the .tar.gz and xmoto.bin could be generated
at build-time. The second solution is IMHO the nicest one.
Cheers,
Samuel.
[EMAIL PROTECTED] wrote:
> Hi,
> the aim of xmoto.bin is to get only one file to deliver instead of a lot of
> them
> (for levels, pictures and whatever we want). Of course, these files must not
> be
> dependant of the architecture.
> The files included into xmoto.bin are not delivered into the tar.gz to not
> deliver them twice ; however, the files are avaible from cvs. The list of the
> files included into xmoto.bin is avaible into bin/Packages.lst. When you work
> on the cvs, if this file is changed, the xmoto.bin is automatically
> regenerated
> (cd bin ; xmoto-edit -pack) rule.
> xmoto-edit -pack search a file called ./Packages.lst, read each line and
> produce
> ./xmoto.bin
> To produce your own xmoto.bin, just get the cvs sources.
> What about unpack it :
> in any case we use an unpack method because we have already the files
> extracted
> into the cvs ; neckelmann did a function vs_file_open("my_file"),
> vs_file_read,
> ... which read from the xmoto.bin (as an extraction), or from the game dir, or
> from ~/.xmoto/
> ~/.xmoto is prior than xmoto.bin, then if you want to make test and replace a
> file which is include into xmoto.bin, just put it into your ~/.xmoto with the
> same arbo.
> These priorities can allow to correct bug into the levels and other filesk
> even
> if the xmoto.bin is not regenerated :
> apt-get install xmoto make xmoto.bin not user writable, then, remake xmoto.bin
> what not the good solution.
>
> One thing is sure : there is no documentation about that except this mail.
> I should add this mail as a wiki entry ;-)
>
> Nicolas
>
>
> Quoting Samuel Mimram:
>
>> Hi,
>>
>> It looks like we have a problem here... Could the tool used to generate
>> xmoto.bin be provided with the sources of xmoto?
>>
>> Thanks!
>>
>> Cheers,
>>
>> Samuel.
>>
>> -------- Original Message --------
>> Subject: Bug#395845: xmoto does not include the source for levels!
>> Package: xmoto
>> Version: 0.2.2-1
>> Severity: important
>>
>> xmoto includes the file xmoto.bin which is a big binary of level files &
>> lua scripts. In the bin directory, there is even a rule to create the
>> xmoto.bin file from the component source files, but those source files
>> are not included in the source package. This means that we are not
>> actually distributing the full source to xmoto and, additionally, it
>> means that it is impossible to easily fix bugs in the level data or
>> their corresponding lua scripts.
>>
>> Either the individual source files that get compiled into xmoto.bin need
>> to be included in the source package, or a clear & easy way to unpack
>> xmoto.bin into these component files needs to be part of the package.
>> Right now xmoto.bin is write-only by xmoto-editor and is only readable
>> by the game itself.
>>
>> (I think that this bug could be fixed most easily just by including the
>> source from which the upstream builds their xmoto.bin.)
>>
>> One argument might be that the xmoto.bin file is just like an "archive"
>> of the files it includes. This is only an acceptable argument if there
>> is an easy way to both archive and unarchive the file contents, which is
>> not currently the case. In addition, there could also be problems if any
>> of the individual files included in xmoto.bin are sourceless, e.g.
>> *compiled* lua scripts. I don't necessarily believe this is the case from
>> the looking I did, but it's something else to watch out for (and hard to
>> tell currently--I just did a quick check with a hex editor).
>>
>> I've marked this bug as "important" rather than "serious"; I'll leave it
>> up to the maintainer or release team to escalate it if necessary.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
