[Debian-ha-maintainers] libqb is ready

[Ferenc Wagner]

Richard B Winters <rik at mmogp.com> writes:

> wferi at niif.hu writes:
>
>> The .tarball-version file is present in the released tarballs.  Upstream
>> does not anticipate that git snapshots would be built without the .git
>> directory being around, but you were doing exactly that.  So you had to
>> provide a .tarball-version file, with the same content that would have
>> been derived from git describe, if it had been possible.  This version
>> string enters libqb.pc, thus is user visible.
>
> It really isn't though, it's not present in the released tarballs,
> please see:  https://github.com/ClusterLabs/libqb/archive/v0.17.1.tar.gz
> (i.e download and extract it, no .tarball-version inside).

You are right, I did not check it, only read the documentation in
build-aux/git-version-gen.  But then I think this is a bug in the
upstream release process, which should be reported and fixed, not
documented.

> And yes, one is generated without any intervention...but then open it
> on up and you will see the value as UNKNOWN rather than 0.17.1...hence
> the need for us to preset it if not built with the .git directory
> intact in the root.
>
>>> The whole point of leaving that note, is so that if another maintainer
>>> does the packaging on the next version, they will know to
>>> leave .tarball-version there, and to remove .version.
>> 
>> It the "next version" is a proper upstream release, then it comes with a
>> proper .tarball-version file, and everything should just work.  Is there
>> any problem with this machinery?
>
> Yes as I explained above, there is no .tarball-version file in the
> original release tarball (its in .orig.tar.gz because I put it there,

Repacking the original tarball has its complications, we'd better avoid
that.

> and that's why I commented in README.debian because:
>
> README.debian: Any extra details or discrepancies between the original
> package and your Debian version should be documented here. [1] 

Yeah, but discrepancies not in source, but in behaviour.

> README.source: 
> If running dpkg-source -x on a source package doesn't produce the source
> of the package, ready for editing, and allow one to make changes and run
> dpkg-buildpackage to produce a modified package without taking any
> additional steps, creating a debian/README.source documentation file is
> recommended. [2]

"[...] debian/README.source may also include any other information that
would be helpful to someone modifying the source package."

>> REAME.Debian is for the users of the binary package, I don't see how
>> this info would be useful there.
>
> See above and follow links, it's what the README.debian is used for,
> spelling out discrepencies between original upstream tarball source and
> our debian package source (such as our .tarball-version file and
> population.

We obviously have different interpretations of the text.

> README.source is for users of the source package, which should
> indicate any extra steps necessary for them to build from the source
> package....but there are none :)

No necessary steps, but an optional piece of information.  Actually, I'm
not sure I'd bother spelling this out at all.

>>> If you can promise that the hyphen and first four characters of the
>>> commit id wouldn't cause an issue
>> 
>> The commit id should never enter the play (unless the public branch is
>> rebased), as the number of commits will always decide.
>
> The autogenerated version that you spoke of (suggested to use) in your
> last email to me, is actually containing a commit id.

Yes, but that part never counts in the sorting, because the previous
part (the number of commits) will never be equal.

>>> Although, I'm afraid Matthew is correct, and Debian likes it's pristine
>>> tarballs...so I will just pacakge the straight version, and patch it as
>>> necessary - leaving git snapshot releases for experimental :)
>> 
>> That's fine with me, too.  Let's hope the little lie in the pkg-config
>> version string won't hurt anybody.
>
> Lie in pkg-config?  What lie?

The pkg-config version comes from the .tarball-version file, thus it's
constant, does not change with each added commit.  But when building
from git, it changes with each commit.  Nevermind.
-- 
Regards,
Feri.