kiwix upstream tarball confusion

Emmanuel Engelhart emmanuel at engelhart.org
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. 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...
> 
> 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:
>>>>> 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?
> 
> 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?
http://download.kiwix.org/src/nightly/2012-11-04/kiwix-20121104_r4138.tar.gz

Emmanuel


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/debian-edu-pkg-team/attachments/20121104/67f3e0fc/attachment.pgp>


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