kiwix upstream tarball confusion

Fri Nov 2 13:35:52 UTC 2012

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

Greets after a too big delay,
Mike

-- 

DAS-NETZWERKTEAM
mike gabriel, rothenstein 5, 24214 neudorf-bornstein
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabriel at das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.alioth.debian.org/pipermail/debian-edu-pkg-team/attachments/20121102/8c165eb4/attachment.pgp>