mirror of
https://github.com/bdnugget/freeminer.git
synced 2026-11-07 06:57:27 +00:00
38 lines
1.5 KiB
Plaintext
38 lines
1.5 KiB
Plaintext
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. |