Re: Co-installable netCDF
On 30/04/2018 15:46, Bas Couwenberg wrote:
> On 2018-04-30 16:05, Bas Couwenberg wrote:
>> Hi Alastair,
>>
>> On 2018-04-30 15:42, Alastair McKinstry wrote:
>>> This is an update to netcdf that I proposed for Debian stretch, but
>>> postponed due to the HDF5 transition of the time.
>>>
>>> I've updated the dev-coinstallable branch of netcdf (on salsa) to bring
>>> it up-to-date with recent netcdf changes.
>>>
>>> This would add two new flavours of netcdf lib, netcdf-mpi and
>>> netcdf-pnetcdf, (lib and -dev packages) to enable parallel IO. This is
>>> designed to match the HDF5 flavour scheme (details below from previous
>>> email), the serial version is left unchanged except for adding symbol
>>> names; no transition is therefore required.
>>>
>>> It is expected that only a handful of packages (ADIOS, XDMF) would be
>>> using the parallel / MPI versions; most packages would continue
>>> unchanged.
>>>
>>> Would it be possible to merge this package for buster?
>>
>> No, because my concerns have not been addressed.
>>
>> The changes to libnetcdf13.symbols are not acceptable.
>>
>> The non-standard library path will break reverse dependencies, and
>> will require a transition.
>>
>> Symbol versioning scripts are still used, which are too hard to
>> maintain properly.
>>
>> There are patches not included upstream, which very much should be
>> accepted upstream before I will consider them appropriate for the
>> Debian package.
>>
>> The changes to debian/rules are far too invasive. Maintaining the
>> SOVERSION there is unacceptable.
>>
>> Most importantly co-installability of the netcdf library variants
>> needs to be supported upstream before I will consider it for the
>> Debian package.
>>
>> Sorry to rain on your parade.
>
> If you want to get a parallel enabled netcdf into buster, you'll need
> maintain a fork of the netcdf package (e.g. netcdf-parallel) which
> provides the MPI and pnetcdf variants, but not the serial variant when
> it conflicts with the libraries built from the netcdf source package.
>
> Since I'm not willing to have parallel changes in the netcdf Debian
> package that are unsupported by upstream, that's probably the best
> compromise.
>
> Reverse dependencies of netcdf can then switch to your netcdf-parallel
> package if they want parallel support. Everyone else can keep using
> the netcdf package without parallel support.
>
> Kind Regards,
>
> Bas
Unfortunately I don't think that would work.
Packages such as VisIT with multiple plugins (NetCDF, ADIOS, etc. ) will
end up pulling in both netcdf libraries.
ADIOS, etc. expect to be MPI-enabled and normally uses parallel NetCDF;
a standard serial NetCDF is needed to support compression.
If serial NetCDF is supplied without versioned symbols, it will collide
and cause errors.
The best solution is to get versioned symbols supported upstream. I'll
prepare (a) patch(es).
regards
Alastair
--
Alastair McKinstry, <alastair@sceal.ie>, <mckinstry@debian.org>, https://diaspora.sceal.ie/u/amckinstry
Commander Vimes didn’t like the phrase “The innocent have nothing to fear,”
believing the innocent had everything to fear, mostly from the guilty but in the longer term
even more from those who say things like “The innocent have nothing to fear.”
- T. Pratchett, Snuff
Reply to: