[Debian-ha-maintainers] libqb is ready

[Richard B Winters]

Hi Feri,

Thanks for your patience with me -

> Looking at http://dep.debian.net/deps/dep14/, let me recommend cloning
> the upstream repo into that new Alioth repo, and use debian/{sid,...}
> branches for packaging.  That is, not using a disconnected Git repo for
> packaging only.

I also see in there that the method I'm using is just fine. It's even
assumed as the first option no? And I've got a question - dep14 is a
draft, the latest accepted dep version is dep5...shouldn't we be
following that? What happens when dep14 is potentially rejected like
several drafts before it?

I don't understand cloning a repository and all of its history -> when
we are supposed to be packaging using the release tarball anyhow -> not
the commit used for the tarball release...no?

--

> For the "official" repo, I'd prefer Alioth, for it's free.

So is Github.com...did you mean to imply something other than this? I
only suggest using Github.com because of all the advanced features we
could be taking advantage of - which Alioth does not have.

--

>> 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.
>
> Not if you just want to rebuild without changing anything.  But
> otherwise it's useful to know how to influence to pkg-config version.

True, ok.

--

>> It should be reported and fixed yes, which I will let upstream know
>> packing a stale .tarball-version file would work wonders for some.
>
> Thanks for opening the issue.  The .tarball-version should not be
> "stale", though, but correct instead.  It carries the upstream
> version.

"Stale" as used by me is as borrowed from upstream's usage. You should
already know I mean to explain to update the version string in it :P

--

> Strangely, the 0.17.0 upstream tarball also does not contain the
> .tarball-version file, but the Debian orig tarball does.  I overlook
> something, or somebody's cheating here...

Considering Martin and Anibal are the only 2 to have uploaded any libqb
package, I'd say it was Martin - and that he did it for the same reason
I did? That or he sponsored someones upload, but they should be noted in
the changelog...

As you've noticed I pinged upstream about the issue -> yet now I'm
confused again;
 
If we package as you suggested (using an upstream clone), then we'll
have the .git directory and that repository will be ignored by using -i
or -I in the build process no? Yet the pristine-tarball created in this
manner (i.e. using upstream repository instead of tarball import) would
be a modified source directory, just as what I've done manually - save
missing the .tarball-version file...why is it an issue for me to do so
manually? It seems a little contradicting to me.

--

> This is an issue when upgrading the package, not present on first
> installs.  Then an empty directory is left behind, which should be
> replaced by the symlink.  Just try installing the sid version, then
> upgrading to your packages.  You'll end up with an empty
> /usr/share/doc/libqb-dev directory instead of the symlink.  It's a 
> dpkg peculiarity, spelled out in the bug report.

Alright no biggie, I can update it.

--

> OK, Speaking about documentation, INSTALL and README.markdown 
> end up in /usr/share/doc/libqb (autoconf docdir) instead of 
> /usr/share/doc/libqb0(see libqb0.install).  Renaming the directory in
> dh_auto_install looks like the easiest solution. > I'd rather put this
> info into README.source, not into rules.

Alright, that makes sense to me, I'll update the location

--

> At the same time you can also directly remove the COPYING file from
> that directory.  It's safer than using find to silently remove all 
> (future)COPYING files.

Yes, I kind of rushed there, reusing the find command from the .la hack
present in the rules file. I'll update that as well.

--

> I'd also just remove the .la file, unless you know it's actually 
> needed (though I doubt it, as it isn't present in 0.17.0-2).

I don't know that it's _not_ needed, and figured as long as we are
following the suggested implementation (clearing the field as suggested
by Debian Policy), there should be no harm done. However, if it is going
to be a problem getting the package sponsored because of this -> I will
gladly remove the file instead of prepping it.

--

> The above boils down to something like:
>
> override_dh_auto_install:
>      dh_auto_install
>      rm debian/tmp/usr/lib/*/lib*.la
>      rm debian/tmp/usr/share/doc/libqb/COPYING
>      mv debian/tmp/usr/share/doc/libqb debian/tmp/usr/share/doc/libqb0
>
> and the corresponding changes in the .install files.

Ok, I'll make some changes and update you in a short while.


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/20150330/4f88b895/attachment.sig>