Hi,
Am Freitag, den 15.04.2011, 16:30 +0530 schrieb Joachim Breitner:
> > > and the same for ghc-7.0.2.
> >
> > I can't see a problem that this would cause. And using this will remove the
> > necessity of upgrading ghc and haskell-devscripts at the same time.
>
> I feel a bit uneasy about changing all of /usr/lib/ghc-{ver}
> to /usr/lib/ghc – who knows in what unexpected places the other path is
> expected. So here is a less intrusive variant of the above idea:
>
> if [ ! -l /usr/lib/ghc-7.0.3/haddock ]
> then
> mv /usr/lib/ghc-7.0.3/haddock/* /usr/lib/haddock
> rmdir /usr/lib/ghc-7.0.3/haddock
> ln -s ../haddock /usr/lib/ghc-7.0.3/haddock
> fi
>
> So we only assemble the haddock files from different ghc versions in a
> shared location, but leave the rest of the file naming systematics the
> same.
and a third, even less intrusive idea: We postbone
renaming /usr/lib/ghc-* to /usr/lib/ghc until the next haddock interface
bump (when we need to rebuild everything anyways). Until the, we hack
haddock to also look in /usr/lib/ghc-7.0.2/haddock if some package
specifies something else and it is not found. Ugly clutch, but no
messing with file locations (where I’m not sure whether we get it right,
even with regards to package upgrades and removals).
After the interface bump, the path is changed to /usr/lib/ghc/haddock
and the patch can be removed again.
Greetings,
Joachim
--
Joachim "nomeata" Breitner
Debian Developer
nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata
Attachment:
signature.asc
Description: This is a digitally signed message part