kiwix upstream tarball confusion

Vasudev Kamath kamathvasudev at
Thu Oct 25 07:18:05 UTC 2012

Hello all,

Mike, Emmanuel are we agreeing for some conclusion on this upstream
naming issue? I see there is new upstream release rc-1 which fixes one
of the crash bug reported recently.

So if we can finalise the naming I will probably go ahead with
importing new version and preparing the package.

Looking forward for reply from Mike

Best Regards

On 12:09 Sat 22 Sep     , Emmanuel Engelhart wrote:
> 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.
> >>>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...
> >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:
> >>>
> >>
> >>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
> _______________________________________________
> Debian-edu-pkg-team mailing list
> Debian-edu-pkg-team at

Vasudev Kamath
Connect on ~friendica: copyninja@{ |}
IRC nick: copyninja | vasudev { |}
GPG Key: C517 C25D E408 759D 98A4  C96B 6C8F 74AE 8770 0B7E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <>

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