Re: sfcgal package for postgis and others
On 29-07-15 14:29, Sven Geggus wrote:
> Sebastiaan Couwenberg wrote:
>
>> sfcgal has been accepted into the archive
>
> finally
sfcgal has had a relative short stay in the NEW queue, several others
had to wait up to 6 months.
>> https://tracker.debian.org/pkg/sfcgal
>>
>> But unfortunately its unstable C++ symbols caused build failures on most
>> architectures:
>>
>> https://buildd.debian.org/status/package.php?p=sfcgal
>
> *argh*
>
> Frankly all this symbols stuff is new to me as up till now everything seemed
> to work without such a file as well (at least for my custom in house
> packages).
Proper library packaging is non-trivial, and required for smooth
transitions.
I've learned quite a lot about this subject especially since I started
to co-mainain gdal. Its split C & C++ symbols make it even more complex.
>> You should switch to pkgkde-symbolshelper from the pkg-kde-tools to
>> handle the C++ symbols
>
> OK, I tried to do this in the same way liblas does and pushed changes to
> git.debian.org
>
> I also increased the Version Number from 1.1.0-1 to 1.1.0-2
>
> Is this correct?
Yes, but incomplete.
Sticking to the dch defaults (`dch -i` for a new package revision) will
set the distribution to UNRELEASED which you should use until all
changes have been be made before the new upload.
pkgkde-symbolshelper uses its own symbols file format in which it keeps
track of the symbols per architecture. It adds a header to the symbols
file like:
# SymbolsHelper-Confirmed: 1.1.0 amd64 i386
You therefor need to recreate the symbols file as documented in:
http://pkg-kde.alioth.debian.org/symbolfiles.html
For C++ libraries like sfcgal we need to upload the first revision to
experimental to have the buildds build the package and generate the
architecture specific symbols.
Once the experimental builds are available you update the symbols for
the other architectures with the buildlogs downloaded by
pkgkde-getbuildlogs and `pkgkde-symbolshelper batchpatch -v
<upstream_version> <log_dir>/*.build`.
So you need to prepare a new revision for experimental, for which I
suggest to version 1.1.0-2~exp1 to have the experimental revision
precede the 1.1.0-2 revision for unstable which will contain the symbols
for the other architectures.
Uploading new upstream releases to experimental first is always a good
idea and strongly encouraged. New upstream releases are likely to
contains a SONAME bump and the library package rename to match it will
cause the package into NEW again. Uploading to experimental prevents the
package from being accepted into unstable at an unfortunate time (e.g.
blocking an ongoing transition because of outdated dependencies, or
starting an uncoordinated transition with its SONAME bump). Transitions
should always be staged in experimental first, the automated transition
tracker will pick up the new library packages in experimental and setup
a tracker.
Even without a SONAME bump uploading to experimental first will prevent
RC bugs on your package in unstable when they fail to build on one or
more of the ports.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Reply to: