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

Re: A smallish transition needed for haskell libraries



On Wed, Jan 14, 2009 at 06:03:18PM -0600, John Goerzen wrote:
> Don't you need to do the upload first, so that dh_haskell_depends does
> the right thing on the built packages?

dh_haskell_depends already does.  dh_haskell_prep doesn't.

If haskell-devscripts was updated first, then it would use "ghc6 (<<
6.8.2+)" as the dependency everywhere.  Currently only
dh_haskell_depends uses this form, not dh_haskell_prep.  With this,
both versions 6.8.2-7 and 6.8.2dfsg1-1 of ghc6 would satisfy this
dependency.

IMHO it's a bug in itself that dh_haskell_depends and dh_haskell_prep
give different versions as the upper limit.  Some packages seem to get
their dependencies from the one, some from the other.  Even if they
amount to the same thing under normal circumstances...

If I uploaded ghc6 first, haskell-hlist etc will be uninstallable
until binNMUed.  Granted, this may just be a small enough evil to not
care about.  There are only 7 of those, at this count (plus some of
John's but those need a sourceful upload).  I wouldn't even
necessarily need to push for a new haskell-devscripts.

Oh, I guess I will just upload that new ghc6 instead.  Hopefully it
won't turn this into a bigger mess.

I'm trying to keep the amount of necessary binNMUs at a minimum.  At
least I avoided almost all of them by not using 6.8.2+dfsg1 as the new
version number.

> I'm willing to upload these quickly when needed.

I suggest that you use t-p-u for the libraries that you have updated
for unstable, like hslogger.  Hopefully the release team can simply do
source-only NMUs that drop ghc6 (<< 6.8.2-999) from the build deps.
But wait until ghc6 is built on all arches.

IMHO it's a bad practice to use ghc6 (<< $version) in build deps.  All
it does is to overspecify and make your packages less binNMUable.

Attachment: signature.asc
Description: Digital signature


Reply to: