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

Re: repacking ossim source code in git.



On 06-01-16 20:59, Rashad Kanavath wrote:
> Okay. If picking only required is making things complex. I can update the
> cmake patch. But they must be updated with every release even though the
> patch can be applied without rejects. Moreover, cmake patch would never get
> into upstream and I thought that add burden of package maintainers.

I'd would like to see separate (tarball) releases of the various ossim
components, and have each include the build system needed for it. That
would make packaging much easier, especially if each component has
proper licensing & copyright information in its files. That's the
biggest problem with all the currently excluded ossim source.

Refreshing patches is common step as part of the procedure to update the
packaging for a new upstream release. Because ossim packaging requires
special care, we need to better document in debian/README.source and
noting the need to update in the patch description is a good idea too.

>>> Last point,
>>> The patch to ossim/CMakeLists.txt seems inappropriate to me. Do we need
>> to
>>> provide both static and shared in the single package ?
>>
>> I don't know why it was added, you should ask frankie who added it. I
>> kept these changes because it was added for a reason, and didn't want to
>> make drastic changes to the ossim package which I only updated to fix
>> some bugs for 1.8.16, and recently to update it to 1.8.20 to assist the
>> OSGeo-Live effort which uses the packaging too.
>>
> 
> All it does is creating a static library called ossimstatic. But this was
> not installed in a separate .install files and IIRC, the build seems to
> ignore it. It gives me libossim.a instead of libossimstatic.a

The static library has been included in libossim-dev since 1.8.16-1, and
it's still installed:

 $ grep libossim.a debian/*install
 debian/libossim-dev.install:usr/lib/libossim.a

libossim-dev also includes the shared library libossim.so, having only
the extension differ between the shared & static library is the common
convention.

> Maybe a static ossim might be required for some other debian packages.

otb is the first package to use ossim, there are no packages in the
archive that use ossim. OSGeo-Live does have other project that require
ossim.

> If package must give both static and shared libs, should we add another
> package libossimstatic  in debian/control to keep it clean ?

No, the .so symlink and the .a library should stay together in the -dev
package.

https://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#id249952

> I would prefer not to keep static and shared in same package if asked. ;)

Why?

Kind Regards,

Bas

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


Reply to: