[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Debian-haskell] RFS: haskell-http



Op ma, 01-05-2006 te 14:29 -0700, schreef Steve Langasek:

> > > I know, but the Depends are strict enough. And when a new version of ghc6
> > > hits unstable haske-http can be bin-NMU-ed. The package is setup that that
> > > should work. So no need for a new upload (and begging for sponsorship)
> > > then.
> 
> > The problem is, with it as-is, you could get unpredictable results.  One
> > platform might have a package that works only with GHC 6.4.1, while the
> > next has one that works only with 6.4.2, due to building it at different
> > times.  I'm not really comfortable uploading it in this state.
> 
> Are there auto-generated binary dependencies that reflect this, though?  If
> so, I don't see any reason to worry about the prospect that a package *may*
> get built against the wrong ghc; if the package is binNMU-safe in the first
> place, then all it takes to fix this is a binNMU...
> 
Yes. The ${haskell:Depends} in the source control file will be
substituted with ghc6 (>= "ghc6 version at build time"), ghc6 (<< "ghc6
version at build time"-999) in the binary control file. 

So while I think my approach is save, I already have uploaded a new
revision to my webserver which Build-Depends on a specific ghc6
version. 

John could you have another look and maybe upload it? When you rebuild
it don't forget the -v0.4.20050430-1 flag for dpkg-buildpackage to make
sure the changelog for -2 revision is also included and the bugs are
closed on upload. The package is available from my website [1], just do
dget http://moonshine.dnsalias.org/debian/unstable/haskell-http_0.4.20050430-3_i386.changes

Greetings Arjan

[1] http://moonshine.dnsalias.org/debian/unstable


complete changelog of my changes:

haskell-http (0.4.20050430-3) unstable; urgency=low
 .
   * debian/rules:
     - remove INSTALL_PROGRAM += -s cruft, we use dh_strip.
     - remove configure and install targets, almost everything is done in
       the binary-arch and binary-indep targets.
   * debian/control.in:
     - remove the versioned dependency on ghc6 version 6.4.2 as it is not
       yet in the archive anyway.
     - Build-Depend on a specific ghc6 version, to make sure the
       libghc6-http-dev package Depends on the same ghc6 version on all
       architectures.
     - Upgrade to Standards-Version 3.7.0. No changes needed.
 .
 haskell-http (0.4.20050430-2) unstable; urgency=low
 .
   * Take over maintainership with permission of previous maintainer.
   * Run update-haskell-control to update the Build-Depends, Depends and
     Architecture lines. (Closes: #337979, #360878, #336396, #336268)
   * Remove support for nhc98 from the package.
   * debian/control.in:
     - Move haskell-http-doc to section doc.
     - Change to Standards-Version 3.6.2. No changes needed.
     - Cleanup the Build-Depends and Build-Depends-Indep
     - Add Homepage: http://www.haskell.org/http/ to the descriptions.
     - Properly escape ${haskell:Depends}.
     - Add versioned libghc6-cabal-dev and ghc6 to the Build-Depends to use
       Cabal version 1.1.1 or later which introduces a new installation
       prefix for libraries.
     libghc6-http-dev determinable.
   * debian/compat: added and set debhelper compatability level to 5.
   * debian/copyright: updated.
   * debian/haskell-http-doc.dirs: added.
   * debian/libhugs-http.install: added.
   * debian/libhugs-http.linda-overrides: added. The *.hs files need to be
     installed in /usr/lib/hugs/ so override linda warning.
   * debian/rules:
     - split the dh_haskell -a -i call two calls. Move all the architecture
       independent stuff to binary-indep and all the architecture dependent
       stuff to binary-arch. (Closes: #315333)
     - remove the empty directory usr/lib/haskell-packages/ghc6/bin
       (Closes: #324718)
     - do not ignore errors on clean and remove redundant make clean call.
     - general cleanup.
   * debian/watch: added watch file.
   * http.cabal: add package base to Build-Depends.





Reply to: