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

[Joachim Breitner]

Hi,

Am Donnerstag, den 18.10.2018, 22:45 +0300 schrieb Ilias Tsitsimpis:
> 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?

there are two ways of solving the problem:
 * ghc starts to Provide+Conflict libghc-mtl-dev
 * ghc stops shipping /var/lib/ghc/package.conf.d/mtl-2.2.2.conf

Judging from
https://ghc.haskell.org/trac/ghc/wiki/Commentary/Libraries/VersionHistory
mtl is indeed now shipped “officially” with GHC. So yes, remove it from
@ignored. The mtl has been in @ignored since 6.12.1, long before I got
involved, so don’t assume it is all up-to-date.

The commit messages in
$ git log -p debian/provided_substvars
are somewhat helpful.

> > >  * 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?

If mtl is now a dependency of, say, ghc or another library provided by
GHC, then you can’t really. I thought there might have been some code
in debian/ to control that, but I don’t see it right now.

> 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).

Oh, yes, that might work indeed.

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

It’s very old to me, which is not much better :-)

Cheers,
Joachim
-- 
Joachim “nomeata” Breitner • nomeata at debian.org • https://j.oach.im/
  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/pkg-haskell-maintainers/attachments/20181018/e36b9843/attachment-0001.sig>