Files
2024-04-28 14:19:27 +02:00
..
2022-02-21 02:30:48 +03:00
wip
2024-04-28 14:19:27 +02:00
fix
2024-04-20 16:37:49 +02:00
2023-04-22 00:37:02 +03:00
2023-04-22 00:37:02 +03:00
fix
2024-04-20 16:37:49 +02:00
2022-02-21 02:30:48 +03:00
2022-02-21 02:30:48 +03:00

TL;DR
*****

We don't use the original upstream tarball, but a repacked version.
It can be easily regenerated by typing:

    make -f debian/rules get-orig-source 


Long version
************

I hate fiddeling with upstream's tarballs, but it seems to be what
upstream expects of us here, so let's do it. I was about creating
separate debian packages (at source level) for each parts, but since
other distros were merging them, I went to upstream IRC channel to
discuss on their motivation to split the source package. 

emptty:    celeron55: why did you guys separate common and the games
           from the main tree? 
celeron55: emptty: common and the games are separated from the engine
           tree to keep the repositories reasonably sized
celeron55: common and games contain textures, sounds and 3D models
           which aren't wanted in the engine repo
emptty:    Is there any possibility that they get versioned
           differently? Like a 0.4.6.1 release of minetest_game while
           the other remain  at 0.4.6 or so.
celeron55: It is intended that they are identically versioned via git
           tags.

If so, I see this split as a convinience for the developers, but I
think that it is expected that we merge the elements back into the
source package in Debian.

I diregarded the creation of several upstream tarballs as it breaks
git-buildpackage. I think that a team-managed package must be as much
automatized as possible. git-buildpackage makes it impossible to have
dissemblable compilation environment among team members.