On Thu, Jul 07, 2016 at 09:40:18AM +0200, Thomas Danckaert wrote:
> It's not a lot of work to submit a patch for HDF-EOS5 with the bundled
> GCTP, but I'm afraid that other packages which depend on two libraries
> that each bundle (a version of) GCTP (such as HDF-EOS2 and HDF-EOS5),
> will run into problems. There would be either a conflict due to
> multiple versions of libGctp, or, if we statically include GCTP in the
> libraries that use it, conflicting symbols when we link those
> libraries, no?
I'm not sure if there will be problems or not... it's unfortunately
beyond my level of expertise :) I've asked someone with more experience
than me to weigh in.
> For this reason, maybe using a separate GCTP package, and adding a
> patch to projects that use it, is the best solution after all?
> Development of GCTP and most packages that depend on it seems to be
> mostly finished anyway, so maintaining the patches might not be that
> much work.
Based on my experience with Guix so far, I think that maintaining our
own forks of 3rd party software is outside of the scope of the Guix
project. I think that the {nix,guix}-daemon is the only software for
which we do this.
If it's not possible to use the bundled GCTPs then we have to use an
external library, but I think it should be maintained outside of Guix.
As you say, it should not be much work to put it on a public Git repo or
to host a tarball, since the development is basically complete.
Too bad no other distros have already packaged it; often we can copy
them ;)
I'm sorry for the loooong delayed reply.
