kiwix upstream tarball confusion

[Emmanuel Engelhart]

Hi Grabriel,

Sorry for being so late with my answer :(

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. http://download.kiwix.org/src/kiwix-0.9~rc1-debian.tar.gz
>>> 2. http://download.kiwix.org/src/kiwix-0.9-rc1-src.tar.gz
>>> 3. ... and kiwix-0.9-rc1-src.tar.gz found here:
>>> http://sourceforge.net/projects/kiwix/files/0.9_rc1/
>>>
>>> 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 autogens.sh 
script for example)?
* coreutils tgz 
(http://ftp.gnu.org/pub/gnu/coreutils/coreutils-8.19.tar.xz) compiles 
without automake for example...

> 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.

> 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...

>> 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:
>>> https://bugs.launchpad.net/ubuntu/+source/kiwix/+bug/1034654
>>
>> 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?

Kind regards
Emmanuel