kiwix upstream tarball confusion

Emmanuel Engelhart emmanuel at
Sun Nov 4 17:50:10 UTC 2012

Le 02/11/2012 14:35, Mike Gabriel a écrit :
> Hi all,
> sorry, I lost of track of this thread... Keeping up with you now.
> On Sa 22 Sep 2012 12:09:00 CEST Emmanuel Engelhart wrote:
>> On 09/06/2012 08:51 AM, Mike Gabriel wrote:
>>>>> Vasudev made me aware of a new 0.9~rc1 release of kiwix and that there
>>>>> are multiple tarballs around with the same version number.
>>>>> I downloaded three src tarballs of 0.9~rc1 (resp. 0.9-r1):
>>>>> 1.
>>>>> 2.
>>>>> 3. ... and kiwix-0.9-rc1-src.tar.gz found here:
>>>>> I downloaded all three of them and the one with -debian in its file
>>>>> name
>>>>> seems to be different:
>>>>> 13c9567f331e487679ce0cabc26ae9fd  kiwix-0.9~rc1-debian.tar.gz
>>>>> 49ab5738b963939d94ecbb6b19b659d8  kiwix-0.9-rc1-src-sf.tar.gz
>>>>> 49ab5738b963939d94ecbb6b19b659d8  kiwix-0.9-rc1-src.tar.gz
>>>>> So my main question is: what is the difference between
>>>>> kiwix-0.9~rc1-debian.tar.gz and kiwix-0.9-rc1-src.tar.gz and what is
>>>>> your motivation to release two tarballs of the same version name.
>>>> We made a Debian version because the Debian contraints on the src.tgz
>>>> file made it not anymore compilable without running automake. We do not
>>>> want do distribute src.tgz which needs automake.
>>> Ok, I understand that. So, from the packaging point of view (and that is
>>> not Debian but any distro, I guess) the optimal/pure/most-generic
>>> tarball is the one that requires automake during the build process.
>> Sorry if I continue to argue ; I probably misunderstand something -
>> but I need to fully understand the point. My questions are why:
>> * make dist generates the "configure" script (and not and
>> script for example)?
>> * coreutils tgz
>> ( compiles
>> without automake for example...
> I recommend using the automake tools from the distro to generate the
> related files. This assures a building standard within the distribution.
> If you ship them in future tarballs, we will remove them anyway. So for
> the distro packagers it will be less work if you leave the autotools
> stuff out of the tarball.
>>> The one with automake generated files provided is a more specific
>>> version of the tarball, so I might guess that there should be the
>>> opposite naming scheme:
>>>   kiwix-0.9~rc1.tar.gz -> the tarball that needs automake
>>>   kiwix-0.9~rc1-<prefconfigured>.tar.gz -> where <preconfigured> stands
>>> for
>>>     automake not being necessary anymore.
>> Why not... I'm pretty open concerning the file naming.. but my feeling
>> is that standards src.tgz files are mostly released with "configure"
>> (and so on without automake dependence) and I need to find a really
>> good reason to not do so.
> Some of them are, probably for convenience of devs und users. As a
> packager for a distro, you will most probably ignore those files.
>>> Any other word than <preconfigured> might work well.
>>> Note: most distributions will expect a tarball that is not preconfigured
>>> by automake, so I strongly recommend providing that tarball under the
>>> more general name.
>>>> The result was in that case:
>>>> kiwix-0.9~rc1-debian.tar.gz
>>>>> And... Unfortunately, I guess, this is not how things work on the
>>>>> Debian
>>>>> side. For a Debian package maintainer, there can only be one tarball
>>>>> named 0.9-/~rc1. (We in Debian prefer the "~" as a delimiter
>>>>> between the
>>>>> upcoming version and ~rcX, ~betaY, ~alphaZ, but that is not crucial
>>>>> here.)
>> We could do that...
> Please, do so. THANKS!
>>>> Which name should be chosen?
>>> See above.
>>>>> So my request is, please help me clarifying this tarball confusion
>>>>> issue. For Debian packaging we rely on you releasing one tarball with
>>>>> one version. Another tarball has to be named with another version.
>>>> Hmm... looks like we have an issue there.
>>>>> We cannot package any new upstream releases for Debian until we have
>>>>> some clarity on the upstream release workflow.
>>>> What do you propose taking in consideration my last explanations.
>>> Switching names of the tarballs and giving the preconfigured tarball an
>>> add-on string in the filename.
>>>>> PS: and what a pity that Ubuntu refuses to build libxul-based
>>>>> applications at the moment:
>>>> Yes, this is a known issue. That's also the reason why we have stopped
>>>> to pushed the last released to our PPA. We have a project in the
>>>> beginning of 2013 to remove the dependence to xulrunner and compile
>>>> directly against Mozilla source code.
>>> I may speak out a warning here in advance... Please make sure that we
>>> (as packagers) do not have to copy the mozilla source tree into the
>>> package in order to be able to build kiwix. That will lead to issues
>>> with Debian policy as it ends up in duplication of a huge code tree
>>> within Debian (see Debian policy 4.13[1] and esp. the footnote (30)
>>> referenced in that paragraph[2]).
>> Having its own runtime is what Mozilla advises to Gecko based software
>> projects. That's the way chosen for example by Thunderbird. Accepting
>> that point, I really do not see how to compile against Mozilla source
>> code without having the mozilla source code in the Kiwix deb src. What
>> do you propose for as an alternative?
> I will give an answer on this in a separate thread.
> So, basically, we need to agree on these points:
>   o no dual src tarball releases, one-version::one-tarball release scheme
>   o include/exclude autotools generated files
> As you are upstream and kiwix is your project, you have to decide about
> inclusion/exclusion. For distro packagers, it will be very helpful to
> exclude those files. I understand that there are cases, where the
> inclusion of auto generated files may be helpful. A tarball that
> includes those files needs to be unwrapped by the Debian maintainer and
> re-packed after the auto-gen files have been removed from the tree. If
> you choose to include such files, we will really appreciate it not to
> change the locations/names of those files (i.e. being very conservative
> with the build mechanism of kiwix or at least notify us about major
> changes in the building strategy).

Could you tell me if everything is OK for you with this tarball?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the Debian-edu-pkg-team mailing list