Bug#989790: libogdi4.1: rename plugin files to include the SOVERSION
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
signature.asc
Description: PGP signature
Bug#989790: libogdi4.1: rename plugin files to include the SOVERSION
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. 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~)
[...]
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.
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. 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/\""
And move the files there.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#989790: libogdi4.1: rename plugin files to include the SOVERSION
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 they paths are versioned in the same way. > The plugins should move to the libogdi-plugins package. One question: are the plugins required for libogdi4.1 to be useful? 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. Cheers > > Kind Regards, > > Bas > > -- > GPG Key ID: 4096R/6750F10AE88D4AF1 > Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#989790: libogdi4.1: rename plugin files to include the SOVERSION
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" The plugins should move to the libogdi-plugins package. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#989790: libogdi4.1: rename plugin files to include the SOVERSION
Package: libogdi4.1 Version: 4.1.0+ds-3 Severity: serious X-Debbugs-Cc: sramac...@debian.org Justification: Debian Policy 8.2 First sentence of 8.2: "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." Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
