RE: proposal for ghc-pkg to use a directory of .conf files
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 agree :-D Over-all I'm kinda neutral about whether HC-pkg needs to be an opaque interface to the packaging system. What are the advantages to this? Well, for one thing it allows us flexibility in how we store the package database. In GHC, I'm using the show/read form of [InstalledPackageInfo] to store the database, but it'd be nice if I could use binary serialisation in the future. To support a directory of config files, we don't have to expose the complete format, though. As long as hc-pkg can process the InstalledPackageInfo to produce the native format into a file, then we just ship that file with the distribution. So I'm fine with this, as long as we're not specifying the contents of the *.conf file. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: proposal for ghc-pkg to use a directory of .conf files
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 by the package don't overlap with another exposed package. 3. if an older version of the package is already exposed, then the older one is supposed to be hidden in favour of the new one Since with the proposed change hc-pkg isn't running on the target system, it can't make any of these tests. GHC can detect at run-time that you have overlapping packages, but then it might not be possible to make changes to the package database (you might need to 'su' in order to do it). The systems that would want to do this kind of thing, such as Debian, have other mechanisms for deciding whether packages conflict, etc. Over-all I'm kinda neutral about whether HC-pkg needs to be an opaque interface to the packaging system. What are the advantages to this? I'm going to write up a proposal about cabal interface changes, which is somewhat related, but also neutral to this. The only question to cabal proper is whether or not 'register' is guaranteed to run on the target. The rest of the LIP does indeed care about this, IMO, so we do need to decide. peace, isaac ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: proposal for ghc-pkg to use a directory of .conf files
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 merging files without any post-install calls to ghc-pkg to modify installed files (ie the global ghc package.conf file) So we can still keep the abstraction of $HC-pkg and gain simpler packaging stuff. Ok, sounds reasonable. I'm going to be working on the package support in ghc and ghc-pkg to improve support for Cabal, so let's do this at the same time. As a Debian packager, I like the idea of changing the way HC-PKG handles individual packages. The question in my mind is whether we want to execute any code on the install target. Previously, I have thought of ./setup register as being a step that happens on the target, no matter what. So if Marcus Makefile wants to do something specifically for the target at install time, this is where he could do it. If we go this route and have the package registration happen at install-in-temp time, then we don't have any standard way to run a post-install script. Some people may prefer that we never execute anything from Cabal on the target, but I would prefer to leave that ability. One solution would be to move the registration step into install-into-temp time, as above, but to add another standard command to Cabal like ./setup postinstall and maybe some others preinst, prerm, postrm as in Debian. This would solve both problems; haskell packages installed with a packaging system like Debian would usually just be moving files into place, but if Marcus or Angela really needed to run something on the target, this is how they'd do it. Thoughts? peace, isaac ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: proposal for ghc-pkg to use a directory of .conf files
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/package.conf.d/ and then final installation is jsut merging files without any post-install calls to ghc-pkg to modify installed files (ie the global ghc package.conf file) So we can still keep the abstraction of $HC-pkg and gain simpler packaging stuff. Ok, sounds reasonable. I'm going to be working on the package support in ghc and ghc-pkg to improve support for Cabal, so let's do this at the same time. As a Debian packager, I like the idea of changing the way HC-PKG handles individual packages. The question in my mind is whether we want to execute any code on the install target. Previously, I have thought of ./setup register as being a step that happens on the target, no matter what. So if Marcus Makefile wants to do something specifically for the target at install time, this is where he could do it. If we go this route and have the package registration happen at install-in-temp time, then we don't have any standard way to run a post-install script. Some people may prefer that we never execute anything from Cabal on the target, but I would prefer to leave that ability. One solution would be to move the registration step into install-into-temp time, as above, but to add another standard command to Cabal like ./setup postinstall and maybe some others preinst, prerm, postrm as in Debian. This would solve both problems; haskell packages installed with a packaging system like Debian would usually just be moving files into place, but if Marcus or Angela really needed to run something on the target, this is how they'd do it. If ./setup register isn't going to run at install time, then I agree we might want ./setup postinst too. 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 by the package don't overlap with another exposed package. 3. if an older version of the package is already exposed, then the older one is supposed to be hidden in favour of the new one Since with the proposed change hc-pkg isn't running on the target system, it can't make any of these tests. GHC can detect at run-time that you have overlapping packages, but then it might not be possible to make changes to the package database (you might need to 'su' in order to do it). Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: proposal for ghc-pkg to use a directory of .conf files
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-pkg to modify installed files (ie the global ghc package.conf file) So we can still keep the abstraction of $HC-pkg and gain simpler packaging stuff. Ok, sounds reasonable. I'm going to be working on the package support in ghc and ghc-pkg to improve support for Cabal, so let's do this at the same time. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: proposal for ghc-pkg to use a directory of .conf files
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 package files for external libraries. OK, just send us a patch and if there are no objections we can merge it into the HEAD. In some ways this looks like a good idea, but it contradicts some of the ideas in the Cabal proposal. There, we were treating the package database as an abstract entity hidden behind the ghc-pkg interface. All interaction with the database would be done via ghc-pkg. The advantages of this abstraction are the usual ones: we might want to change the representation, and the ghc-pkg tool provides a good place to add backwards compatibility if necessary. However, I'm prepared to be persuaded. The just put a file in this directory approach to installation is very compelling, being much more transparent. But bear in mind that if we pick this route, then backwards compatibility has to be built into the file format (I think it might be already, but we're planning changes in this area to better support Cabal). Also, there needs to be a way to find the location to install the file - asking ghc or ghc-pkg is the usual way. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: proposal for ghc-pkg to use a directory of .conf files
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 might like to enforce a policy of using a directory of package files for external libraries. In some ways this looks like a good idea, but it contradicts some of the ideas in the Cabal proposal. There, we were treating the package database as an abstract entity hidden behind the ghc-pkg interface. All interaction with the database would be done via ghc-pkg. There's no reason why we can't do both. You can register a package using ghc-pkg and it can create a separate file in a package conf directory (after expanding env vars and doing auto ghci libs if necessary). The standard way to build binary packages for Linux/BSD distros is to build and install into a temporary directory, then the package manager tars up those files and merges them into the filesystem on the target machine. The package manager remembers all the files it merged so it can removed them or upgrade them later. 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-pkg to modify installed files (ie the global ghc package.conf file) So we can still keep the abstraction of $HC-pkg and gain simpler packaging stuff. Duncan ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: proposal for ghc-pkg to use a directory of .conf files
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/remove. The other advantage is that there is no longer a global file that needs to be modified which means uninstallation is cleaner (most package managers do not remove files that were modified after installation). These are exactly the reasons why e.g. the configuration files for apache2 on my SuSE Linux 9.1 are set up this way. It's very handy, clean and modular. [...] I had a peak at the code in ghc for dealing with .conf files. I'd guess it'd be best ok just check if the specified package file is a directory or an ordinary file and act accordingly. Ie you could say -package-conf packages/ and ghc could by default read from $HC-LIB/package.conf and $HC-LIB/package.conf.d/ or something. Sounds resaonable to me. I can't see any downsides of doing it this way. 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 package files for external libraries. OK, just send us a patch and if there are no objections we can merge it into the HEAD. Cheers, S. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
