pre-install script?

General talk about packaging procedures and packages.
Post Reply
User avatar
mimosa
Salix Warrior
Posts: 3311
Joined: 25. May 2010, 17:02
Contact:

pre-install script?

Post by mimosa »

install/doinst.sh runs *after* package installation. Is there a way to make a script run *before*?

I'd like to borrow the approach taken by the Arch GHC package and unregister Cabal packages (if that's the correct term) before the installation, then giving instructions as to how to go about re-registering them with the new GHC. That way anyone who is upgrading can avoid a mess. I'm not sure but I think if you don't do this, none of the existing stuff you may have installed with Cabal works. I dare say it's fixable, but it would be tidier to deal with it in the package as far as possible.
User avatar
gapan
Salix Wizard
Posts: 6238
Joined: 6. Jun 2009, 17:40

Re: pre-install script?

Post by gapan »

No, there is no such thing, but honestly, if you find yourself in need of something like this, you're probably doing something wrong...
Image
Image
User avatar
mimosa
Salix Warrior
Posts: 3311
Joined: 25. May 2010, 17:02
Contact:

Re: pre-install script?

Post by mimosa »

Assuming there is only one version of the GHC package per Salix version, it shouldn't be necessary; but there is already going to be a second one. The trouble as I understand it is that Cabal (which installs Haskell packages and does package management, so for instance you can just do

Code: Select all

cabal install xmonad
simple as that) links its packages to the GHC version. If you install a new version of GHC, none of that works any more, and you have to "de-register" everything and do it again. I don't know whether it is strictly necessary to do the de-registering while you still have the old GHC - maybe after the upgrade works as well. I also don't know whether this applies only to version upgrades (which would let Salix off the hook assuming no GHC version upgrades are packaged between Salix versions) or to any new build (in which case it may be a problem).

For people doing serious Haskell development, this is a potential annoyance. I don't know enough myself to tell whether the Arch package is just dotting its i's and crossing its t's, or whether this tweak meets a real need. Anyway, since it isn't possible in Slackware, I will ignore the issue and wait for users to complain.

What I am hoping to provide is packages for GHC and the Haskell Platform (a separate package including "batteries", particularly the above-mentioned Cabal). It would then be up to users (including myself) to work out how it all works. I gather things can get a bit messy. :mrgreen:
User avatar
gapan
Salix Wizard
Posts: 6238
Joined: 6. Jun 2009, 17:40

Re: pre-install script?

Post by gapan »

mimosa wrote:Assuming there is only one version of the GHC package per Salix version, it shouldn't be necessary; but there is already going to be a second one.
Is there going to be a second version, or a second package using the same version? I thought it was going to be a package "fix"
mimosa wrote:... links its packages to the GHC version. If you install a new version of GHC, none of that works any more, and you have to "de-register" everything and do it again.
Is it the same if you install a different package (compiled in a different way) of the same version?
Image
Image
User avatar
mimosa
Salix Warrior
Posts: 3311
Joined: 25. May 2010, 17:02
Contact:

Re: pre-install script?

Post by mimosa »

It's the same GHC version, and I don't know whether that means it's not a problem. I also don't know whether it makes any difference whether this step is performed before or after the upgrade. The length of time required to build the package makes trial-and-error testing cumbersome. I've done a lot of that already just to get an apparently correct and complete build.

I say go with the package I am about to submit, and await user responses. My guess is anyone who might care also knows how to fix it, if broke it is - or ought to know better than to allow ghc to be upgraded without doing whatever housekeeping first. The "solution" offered by that Arch package is no great shakes anyway: just unregister the packages (before the upgrade) then print a message telling the user how to go about putting everything back again. Indeed I can't find this any more, perhaps it was an earlier version or from a different distro ...
http://people.salixos.org/mimosa/packag ... 2/PKGBUILD
Note particularly this explanation:

Code: Select all

# Special note for devs looking to upgrade this package:
#   ghc places a unique hash for each library when it is built.
#   Libraries depend on versions specified by those hashes.
#   This implies that all libraries need to be rebuilt when ghc is rebuilt.
Post Reply