<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Haskell Cabal, now with extra crunchy RPM goodness</title>
	<atom:link href="http://www.serpentine.com/blog/2007/02/20/haskell-cabal-now-with-extra-crunchy-rpm-goodness/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.serpentine.com/blog/2007/02/20/haskell-cabal-now-with-extra-crunchy-rpm-goodness/</link>
	<description>Bryan O&#039;Sullivan&#039;s blog</description>
	<lastBuildDate>Wed, 08 Feb 2012 06:41:38 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Tom Moertel</title>
		<link>http://www.serpentine.com/blog/2007/02/20/haskell-cabal-now-with-extra-crunchy-rpm-goodness/comment-page-1/#comment-20132</link>
		<dc:creator>Tom Moertel</dc:creator>
		<pubDate>Wed, 21 Feb 2007 08:04:43 +0000</pubDate>
		<guid isPermaLink="false">http://www.serpentine.com/blog/2007/02/20/haskell-cabal-now-with-extra-crunchy-rpm-goodness/#comment-20132</guid>
		<description>Bryan,

As a fellow Fedora Core user, I am delighted to learn of your RPM additions to Cabal. I&#039;ve written more than a few spec files for Haskell packages in the past, and I look forward to the day when I&#039;m free of that task.

Let me point out a wrinkle I encountered when registering RPM-installed packages with GHC. When upgrading an RPM file that contains the same Cabal name+version of a package as the previously installed version (say with only an RPM release being different), the %pre, %post, %preun, and %postun scripts will all be asking GHC to register/unregister what it thinks are the same library. As a result, when the %preun script is called, which occurs *after* the new package is installed but before the old package is removed, its unregister script will actually unregister the newly installed library, leaving the new library unregistered with GHC.

To test for the problem, take the existing spec file for an already-installed package, bump its RPM release, rebuild the RPMs, and then try to upgrade to the new version. After the upgrade, GHC will no longer know about the package.

To avoid this problem, I&#039;ve worked out the following spec-script dance:

&lt;code&gt;
# SCRIPTS
#
# Scripts for registering/unregistering w/ GHC.  Note that
# the scripts are called in the following order during an upgrade:
#
#   %pre	for new version of package being installed
#   ...		(all new files are installed)
#   %post	for new version of package being installed
# 
#   %preun	for old version of package being removed
#   ...		(all old files are removed)
#   %postun	for old version of package being removed


%pre
# in case we&#039;re upgrading to a library having the same Cabal
# name+version as the currently installed library, we need to
# unregister the old library first, so that the register script in
# %post may succeed.  (note that this command runs *before* the new
# package&#039;s files are installed, and thus will execute the *previous*
# version&#039;s unregister script, if the script exists in the same location
# as the about-to-be-installed library&#039;s script)
[ &quot;$1&quot; = 2 ] &amp;&amp; %{pkgscripts}/unregister.sh &gt;&amp; /dev/null &#124;&#124; :

%post
%{pkgscripts}/register.sh &gt;&amp; /dev/null

%preun
# always unregister the library before we remove its files
# (see %postun, however)
%{pkgscripts}/unregister.sh &gt;&amp; /dev/null &#124;&#124; :

%postun
# if we&#039;re upgrading, the %preun step may have unregistered
# the *new* version of the library (if it had an identical
# Cabal name+version, even though the RPM release differs);
# therefore, we must attempt to re-register it
[ &quot;$1&quot; = 1 ] &amp;&amp; %{pkgscripts}/register.sh &gt;&amp; /dev/null &#124;&#124; :
&lt;/code&gt;

I hope all that makes sense. Anyway, feel free to borrow this logic for your additions to Cabal.

If I can help in any other way, please let me know.

Cheers, Tom.</description>
		<content:encoded><![CDATA[<p>Bryan,</p>
<p>As a fellow Fedora Core user, I am delighted to learn of your RPM additions to Cabal. I&#8217;ve written more than a few spec files for Haskell packages in the past, and I look forward to the day when I&#8217;m free of that task.</p>
<p>Let me point out a wrinkle I encountered when registering RPM-installed packages with GHC. When upgrading an RPM file that contains the same Cabal name+version of a package as the previously installed version (say with only an RPM release being different), the %pre, %post, %preun, and %postun scripts will all be asking GHC to register/unregister what it thinks are the same library. As a result, when the %preun script is called, which occurs *after* the new package is installed but before the old package is removed, its unregister script will actually unregister the newly installed library, leaving the new library unregistered with GHC.</p>
<p>To test for the problem, take the existing spec file for an already-installed package, bump its RPM release, rebuild the RPMs, and then try to upgrade to the new version. After the upgrade, GHC will no longer know about the package.</p>
<p>To avoid this problem, I&#8217;ve worked out the following spec-script dance:</p>
<p><code><br />
# SCRIPTS<br />
#<br />
# Scripts for registering/unregistering w/ GHC.  Note that<br />
# the scripts are called in the following order during an upgrade:<br />
#<br />
#   %pre	for new version of package being installed<br />
#   ...		(all new files are installed)<br />
#   %post	for new version of package being installed<br />
#<br />
#   %preun	for old version of package being removed<br />
#   ...		(all old files are removed)<br />
#   %postun	for old version of package being removed</code></p>
<p>%pre<br />
# in case we're upgrading to a library having the same Cabal<br />
# name+version as the currently installed library, we need to<br />
# unregister the old library first, so that the register script in<br />
# %post may succeed.  (note that this command runs *before* the new<br />
# package's files are installed, and thus will execute the *previous*<br />
# version's unregister script, if the script exists in the same location<br />
# as the about-to-be-installed library's script)<br />
[ "$1" = 2 ] &amp;&amp; %{pkgscripts}/unregister.sh &gt;&amp; /dev/null || :</p>
<p>%post<br />
%{pkgscripts}/register.sh &gt;&amp; /dev/null</p>
<p>%preun<br />
# always unregister the library before we remove its files<br />
# (see %postun, however)<br />
%{pkgscripts}/unregister.sh &gt;&amp; /dev/null || :</p>
<p>%postun<br />
# if we're upgrading, the %preun step may have unregistered<br />
# the *new* version of the library (if it had an identical<br />
# Cabal name+version, even though the RPM release differs);<br />
# therefore, we must attempt to re-register it<br />
[ "$1" = 1 ] &amp;&amp; %{pkgscripts}/register.sh &gt;&amp; /dev/null || :<br />
</p>
<p>I hope all that makes sense. Anyway, feel free to borrow this logic for your additions to Cabal.</p>
<p>If I can help in any other way, please let me know.</p>
<p>Cheers, Tom.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

