[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

SAGA 2.2.6

Hi Johan,

On 03/04/2016 09:41 PM, Sebastiaan Couwenberg wrote:
> On 04-03-16 19:57, Sebastiaan Couwenberg wrote:
>> I've addressed all except the SONAME/symbols lintian issues, and I've
>> fixed the version specific virtual package provided by libsaga which
>> hadn't been updated properly for the past few upstream releases.
> If you don't want to split the libraries into separate version dependent
> packages to match to SONAME, a lintian override should be added to
> override the package-name-doesnt-match-sonames warning.
> The no-symbols-control-file tags should be overridden too, the
> saga-depends executable and the version specific virtual package
> provided by libsaga should take care of that. Although the saga-depends
> executable can probably be replaced with an shlibs file to not have to
> deal with symbols files for C++.

The above issues remain in the SAGA 2.2.6 packaging.

The saga-depends executable and version specific virtual package need to
be updated for every new upstream release because they include the full
upstream version.

I've added a templates target also used in the grass packaging to set
the upstream version in debian/control & debian/saga-depends. You can
call this manually to update the files in git, and it's also a
dependency of the override_dh_auto_configure target to have the files
regenerated from the .in templates for every build.

>> The packaging work for SAGA 2.2.5 also resulted in a number of bugreport
>> in the upstream issue tracker. The most imported being the changes to
>> the gridding module causing a FTBFS due to not supporting
>> --disable-triangle properly any more.
>> https://sourceforge.net/p/saga-gis/bugs/
>> I'll rebase my changes on top of the changes by Johan and push those to
>> Alioth too.
> I've pushed my changes to Alioth. It includes a change to move
> /usr/share/saga to the new saga-common arch:all package which will
> require a pass through NEW.
> What do you want to do about the triangle related build failure? I've
> included a patch to exclude the gridding module to allow the build to
> succeed. Do you want to wait for a fix from upstream before uploading
> the package?

The triangle & gridding module issues are fixed upstream, making the
package pretty much ready for upload now.

Because the package will have to pass the NEW queue for saga-common, now
is a good time to split libsaga into separate packages matching the
SONAME (libsaga-api-2.2.6 & libsaga-gdi-2.2.6). Because the upstream
version is part of the package name then, you don't need to saga-depends
helper and virtual libsaga-2.2.6 package any more.

Do you want to split the library package or rather keep them bundled in
libsaga for now?

Kind Regards,


 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Reply to: