[Haskell-cafe] Re: [Haskell] ANNOUNCE: usb-0.1

[Duncan Coutts]

On Thu, 2009-10-01 at 16:22 +0200, Martijn van Steenbergen wrote:
> Roel van Dijk wrote:
> > Yes, that happens. I don't now the cause but the work-around is easy.
> > Simply download the package manually from hackage, unpack and install
> > using cabal.
> > 
> > At least the following packages suffer from this problem:
> >   bindings-common
> >   bindings-libusb
> >   bindings-posix
> > 
> > Perhaps Maurí­cio can shed some light on this.
> 
> That's odd, even cabal unpack fails. Smells like a cabal bug. :-) I'll 
> see if I can find if it's been reported before.

I suspect it is a bug in the tar code (a copy of which is used in
cabal-install).

Most .tar files contain entries for the directories that precede the
entries for the files. This is only by convention however. It looks like
this tar file has an entry for "src/Bindings/SomeFile.hs" without any
preceding entries for "src/AnotherFile" or for the directory itself
"src/Bindings/".

The bug is that while the tar code would create the "src/" directory for
a file entry "src/AnotherFile", it would not create the "src/" directory
for "src/Bindings/SomeFile.hs", just try to create the "src/Bindings"
directroy, which then fails since "src/" does not yet exist.

I was trying to avoid making all parent directories in a fully recursive
way. In particular I don't want it to make the target root directory if
it did not already exist. I guess it should at least make the
directories between the target root and the directory containing the
file to be unpacked.

If someone wants to make a patch for this then please do it against the
tar package code:

darcs get http://code.haskell.org/tar/

Note that tar files constructed using cabal sdist should not have this
particular problem due to the order of entries within the archive.

Duncan