Bug#910480: ghc: missing Breaks+Replaces+Provides for newly bundled libraries

[Ilias Tsitsimpis]

Hi Joachim,

Thank you for taking the time to answer my questions.

On Thu, Oct 18, 2018 at 08:43PM, Joachim Breitner wrote:
> Am Donnerstag, den 18.10.2018, 12:56 +0300 schrieb Ilias Tsitsimpis:
> > There seems to exist the debian/provided_substvars script which tries to
> > add Provides+Conflicts for ghc's bundled libraries, but for some reason
> > mtl is explicitly ignored. I am not sure why this (as well as other
> > packages) are being ignored, so I have CC-ed Joachim who wrote that
> > script.
> 
> I think these are packages that come with the GHC source (e.g. to build
> other included tools), but that we do not want to provide from the ghc
> package, as there is a separate stand-alone package doing that.

I think I may be missing something, so let me take libghc-mtl-dev as an
example. GHC-8.4.3 includes the mtl library which was not included in
GHC-8.0.2. The Debian package for ghc-8.4.3 does not provide
libghc-mtl-dev, because, as you said, there is a separate, stand-alone
package doing that. But then, libghc-mtl-dev fails to install with:

   trying to overwrite '/var/lib/ghc/package.conf.d/mtl-2.2.2.conf',
   which is also in package libghc-mtl-dev 2.2.2-2

as the mtl library is already provided by ghc (see #910008).

It seems to me that the Debian ghc package needs to Provides+Conflicts
with libghc-mtl-dev as it does with libghc-cabal-dev. Is there anything
special with mtl or any of the other packages that are excluded by that
list?

> >  * Remove all ignored libraries except for ghc, although I believe we
> >     can safely remove that too, and Provide/Conflict libghc-ghc-dev.
> >     @nomeata please comment on whether this is the right approach.
> 
> If you start actually providing them with ghc, then yes. But it would
> mean that you cannot upgrade them independently any more.

How can I choose which libraries are provided by ghc? Taking mtl again
as an example, how can I tell ghc to not install the mtl library, and
provide it through a separate package?

Also, wouldn't we be able to upgrade them independently, if we used
versioned Conflicts (as has been previously be done for libghc-cabal-dev)?
Take libghc-stm-dev as an example. GHC-8.4.3 provides stm-2.4.5.0 but
the user should be able to install libghc-stm-dev-2.4.5.1 if the Debian
ghc package Conflicts with libghc-stm-dev (<< 2.4.5.1).

Again, thank you very much for you input, this is all new to me.

-- 
Ilias