Hello again!
On 22.04.2013 11:19, Dmitry Smirnov wrote:
[...]
> Please commit whatever you have even if it's not perfect. :)
> If you made the game playable it is already in better shape that it was when I
> left it.
>
I have committed a working version to our git repository.
http://anonscm.debian.org/gitweb/?p=pkg-games/freeorion.git
>> * I think FreeOrion should be splitted in two source packages freeorion
>> and freeorion-data. That would save us some bandwith.
>
> As far as I understand the issue by splitting we can save some resources on
> buildd servers. Is there are any other benefits given that we generate
> orig.tar from single repository checkout?
> In any case I trust you with this decision.
I gave it another thought. I believe the Games Team has some kind of
policy in place which recommends splitting large packages in two source
packages. We already do that for 0ad, redeclipse, sauerbraten or
openarena. I guess the main reason for this is to avoid downloading the
large data package every time you have to change something in the binary
package because normally the data package has a strict dependeny like
freeorion-data (= ${source:Version})
On the other hand i can imagine we stick with the status quo and just
change the dependency to
freeorion-data (= ${source:Upstream-Version})
This would be a less strict dependency on freeorion-data and we do not
have to deal with a second source package. I'm undecided now. I think
the compilation of the binary package is the most crucial factor for the
buildd servers. So in case of FreeOrion one source package splitted in
freeorion and freeorion-data might be acceptable, too.
[...]
>> * I agree with you that we should stick with FreeOrions's gigi fork. It
>> is better maintained and we only need the library for the game. I
>> have tested gigi as a standalone package and as part of FreeOrion's
>> build process. I'm willing to create a separate package because i
>> think it is easier to maintain in the long-run. At first it looks
>> like more work but it is easier to spot errors and to fix bugs
>> related to gigi. The rules file of FreeOrion also looks tidier. :)
>> So i'm not afraid to package the library as libgigi-freeorion to make
>> it clear that it is a FreeOrion fork of gigi in case someone intends
>> to package the original library.
>>
>
> I trust you with this decision but I don't see any value in splitting
> freorion's gigi to its own package whatever its name would be. Why don't we
> just leave gigi's RFP open with comment that there is an embedded copy in
> freeorion?
> It's remain to be seen whenever gigi will be valuable for anything but
> freeorion. In case if gigi ever mature into proper library it can be easily
> splitted to its own package then.
>
> I'm concerned about maintenance effort. It appears to me that even if
> freeorion's "rules" may look tidier the overall maintenance effort for two
> packages built from same source tree might be greater comparing to bundled
> libgigi. Ultimately if separating gigi to its own package is convenient to you
> it is enough for me to justify the effort (i.e. I'm not against it I just
> don't see the value of standalone gigi package).
Ok, that's true but then i need to investigate carefully the
dpkg-shlibdeps warning:
error: couldn't find library libGiGi.so'
Strangely it does seem to work anyway.
I see you have changed the LD_LIBRARY_PATH in debian/rules but something
is still missing, hmm. If i can find a solution i could avoid making a
standalone version of libgigi.
Back to work ;)
Markus
Attachment:
signature.asc
Description: OpenPGP digital signature