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 • nome...@debian.org • https://j.oach.im/
signature.asc
Description: This is a digitally signed message part