Bug#989790: libogdi4.1: rename plugin files to include the SOVERSION

[Sebastian Ramacher]

On 2021-06-13 14:08:21 +0200, Sebastiaan Couwenberg wrote:
> On 6/13/21 12:02 PM, Sebastian Ramacher wrote:
> > On 2021-06-13 11:53:00 +0200, Sebastiaan Couwenberg wrote:
> >> On 6/13/21 11:36 AM, Sebastian Ramacher wrote:
> >>> "If your package contains files whose names do not change with each
> >>> change in the library shared object version, you must not put them in
> >>> the shared library package."
> >>
> >> The files should no included in libogdi4.1:
> >>
> >>  "you must not put them in the shared library package"
> > 
> > It's fine if the paths are versioned in the same way.
> 
> There is no versioning of the path.
> 
> >> The plugins should move to the libogdi-plugins package.
> >> One question: are the plugins required for libogdi4.1 to be useful?
> 
> I think so. I don't really use ogdi, I only maintain the package because
> its a dependency of gdal.
> 
> > If
> > so, that would require a Depends from libogdi4.1 on libogdi-plugins and
> > breaking coinstallability once again. In that case, the libogdi-plugins
> > package also needs to be versioned and the paths will need to be
> > versioned again.
> 
> Since the path of the modules are unversioned, the package name
> shouldn't be either.

I'd argue that's the bug. The path of the modules should be have been
versioned in the first place. With what you describe below, they are
tightly coupbled to libogdi.

> Having Breaks/Replace should suffice:
> 
>  Package: libogdi4.1
>  Architecture: any
>  Depends: libogdi-modules (= ${binary:Version}),
>           ${shlibs:Depends},
>           ${misc:Depends}
>  Suggests: ogdi-bin
>  Breaks: libogdi3.2 (<< 4.0.0)
>  Replaces: libogdi3.2 (<< 4.0.0)
>  [...]
> 
>  Package: libogdi-modules
>  Architecture: any
>  Depends: ${shlibs:Depends},
>           ${misc:Depends}
>  Breaks: libogdi3.2 (<< 4.0.0),
>          libogdi4.0 (<< 4.1.0),
>          libogdi4.1 (<< 4.1.0+ds-4~)
>  Replaces: libogdi3.2 (<< 4.0.0),
>            libogdi4.0 (<< 4.1.0),
>            libogdi4.1 (<< 4.1.0+ds-4~)
>  [...]

No, please no. The goal is to have libogdi3.2 and libogdi4.1
co-installable.

> 
> I don't want to diverge further from upstream, the buildsystem is hacked
> enough as it is. The packaging per the above should be policy compliant.

It might follow the letter, but not the spirit. The goal of this section
is to have shared library packages co-installable to make upgrades
easier. The above doesn't achieve that.

> 
> But is seems that the modules require libogdi, the dependency gets set
> via shlib:Depends which introduces a circular dependency:
> 
>  intra-source-package-circular-dependency libogdi-modules libogdi4.1
> 
> Splitting the modules out into a separate package may not be such a good
> idea after all.

ACK

> The module path is built into libogdi via
> 
>  -DMODULES_PATH="\"$(INST_LIB)/ogdi/\""
> 
> And is used by ecs_OpenDynamicLib() to dlopen() the modules.
> 
> I guess we'll have to patch the makefile to use:
> 
>  -DMODULES_PATH="\"$(INST_LIB)/ogdi/4.1/\""

Let's do that instead, please.

Cheers
-- 
Sebastian Ramacher
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-grass-devel/attachments/20210613/3f6d0344/attachment.sig>