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