[Debian-ha-maintainers] libqb is ready

Richard B Winters rik at mmogp.com
Sun Mar 29 04:39:36 UTC 2015


Hi Feri,

One more:

On Sat, 2015-03-28 at 23:24 +0100, Ferenc Wagner wrote:
> >   * debian/README.debian: Added in order to spell out conditions 
> >     necessary for user to be able to run pkg-config --modversion 
> >     successfully post install of libqb-dev
> 
> Isn't README.source a better place for this?  You could also point to
> build-aux/git-version-gen for further explanation.  And I think its
> value in the package (0.17.1) is incorrect: if I build from git I see
> VERSION = 0.17.1.9-8355 in the created Makefile.

This is actually not right, because the tarball-version file is not
needed to be created by us, and when we package the next version we will
increment the value inside ourselves.

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.

Once the package is made there is no editing necessary to build from
package source - therefore README.source would be the inappropriate
place to put that documentation. README.debian would be correct here.

Also, I versioned it as 0.17.1+git.9.xxx

the .9 is consistent with the .9 in the version you see...it means 9
commits since the release tag.

Rather than 8335 (which is the first 4 characters from the commit Id ->
I used the commit Id with a . separator, so that the value is properly
compared to previous versions.

using uscan with the way I versioned it works...we'll get notified when
the next release commit is tagged as a release only obviously. I wanted
to use a scheme consistent with how it's already being done (look at all
the packages for ubuntu that madkiss - Martin - is working on).

However, if I had used that provided version string, take into
considering this example:

v0.17.1.9-8335 is released, we package with that version string.

- No issue

v0.17.1.10-ae34 is released, we package with that version string.

- Not sure exactly what it equates to, but -ae34 is a larger evaluation
than -8335. This particular example might be ok though...could work with
no issues on debian...

v0.17.1.11-1111 is released, uscan was run, but since 11-1111 is
actually a smaller number than 10-aa34 (remember letters and hyphens
increase the value, a hyphen does _not_ create a new version segment) so
it is not a properly increased version. Debian does not like this
updated package because the version is not greater than the latter.


If you can promise that the hyphen and first four characters of the
commit id wouldn't cause an issue, I could go along with your
suggestion, but even Martin is doing something almost identical to me
with the ubuntu packages...likely for the same reasons.

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


Best,


-- 
Rik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/debian-ha-maintainers/attachments/20150329/b0edb51f/attachment-0001.sig>


More information about the Debian-ha-maintainers mailing list