Duncan Coutts wrote:
[...] The advantage of doing this is that it makes things easier for the
package managers. Each individual file can belong to the appropriate
package and so instead of having to execute registration/unregistration
actions on install/uninstall it's just another file to add/remov
On 06 November 2004 10:10, Sven Panne wrote:
> Duncan Coutts wrote:
>> I can knock up a proof of concept patch if anyone thinks this is a
>> good idea. It should be totally backward compatible, it's ok to use
>> both, but ditro packagers might like to enforce a policy of using a
>> directory of pa
On Mon, 2004-11-08 at 14:36, Simon Marlow wrote:
> On 06 November 2004 10:10, Sven Panne wrote:
>
> > Duncan Coutts wrote:
> >> I can knock up a proof of concept patch if anyone thinks this is a
> >> good idea. It should be totally backward compatible, it's ok to use
> >> both, but ditro packagers
On 08 November 2004 18:47, Duncan Coutts wrote:
> We can use ghc-pkg at the build / install-into-temp phase to create
> the $(package).conf files under
> $TMP_INSTALL_ROOT/usr/lib/ghc-$VER/package.conf.d/ and then final
> installation is jsut merging files without any post-install calls to
> ghc-p
"Simon Marlow" <[EMAIL PROTECTED]> writes:
> On 08 November 2004 18:47, Duncan Coutts wrote:
>
>> We can use ghc-pkg at the build / install-into-temp phase to create
>> the $(package).conf files under
>> $TMP_INSTALL_ROOT/usr/lib/ghc-$VER/package.conf.d/ and then final
>> installation is jsut merg
On 09 November 2004 17:36, Isaac Jones wrote:
> "Simon Marlow" <[EMAIL PROTECTED]> writes:
>
>> On 08 November 2004 18:47, Duncan Coutts wrote:
>>
>>> We can use ghc-pkg at the build / install-into-temp phase to create
>>> the $(package).conf files under
>>> $TMP_INSTALL_ROOT/usr/lib/ghc-$VER/pa
"Simon Marlow" <[EMAIL PROTECTED]> writes:
(snip)
> There's another thing that bothers me though: when you install a package
> using hc-pkg, a number of checks are made:
>
> 1. there isn't already a package with that name/version
>
> 2. If the package is to be exposed, then the modules provided
On 21 November 2004 00:56, Isaac Jones wrote:
> The systems that would want to do this kind of thing, such as Debian,
> have other mechanisms for deciding whether packages conflict, etc.
IIRC, this is the argument I just used against adding support for
multiple libraries in Cabal, so I guess I ag
