Bug in Cabal?
Duncan Coutts
duncan.coutts at worc.ox.ac.uk
Wed Jan 21 04:19:09 EST 2009
On Tue, 2009-01-20 at 16:56 +0000, Dominic Steinitz wrote:
> I couldn't seem to logon to the trac to report this.
The details are on the hackage trac front page:
http://hackage.haskell.org/trac/hackage/
If you don't want to register an account you can use the guest account.
User name is "guest" and password "haskell'" (note the apostrophe at the
end).
> I'm working on windows (not linux as the chmod might suggest).
XP or Vista?
> zlib-0.5.0.0>runghc Setup.hs
> configure --package-db=..\..\ghc\ghc-6.10.1\fpf.package.conf
> --docdir=..\..\haskell_packages\doc\zlib-0.5.0.0
> --libdir=..\..\haskell_packages
> --bindir=..\..\haskell_packages\bin
> Configuring zlib-0.5.0.0...
>
> zlib-0.5.0.0>runghc Setup.hs build
> Preprocessing library zlib-0.5.0.0...
> Building zlib-0.5.0.0...
> ghc-6.10.1\bin\ar.exe: creating dist\build\libHSzlib-0.5.0.0.a
>
> zlib-0.5.0.0>runghc Setup.hs
> install
> Setup.hs: ..\..\haskell_packages\doc\zlib-0.5.0.0\.copyFile920.tmp: copyFile:
> permission denied (Access is denied.)
>
> Cabal seesm to create certain things as read only. I can work around this by
We use System.Directory.copyFile which copies the permissions from the
original file to the destination file. Could you confirm that this is
working correctly. Are the permissions of the source and destination
files exactly the same? Was the source file created read-only?
> chmod a+w ..\ThirdParty\haskell_packages\zlib-0.5.0.0\ghc-6.10.1\include\*
>
> chmod a+w ..\ThirdParty\haskell_packages\doc\zlib-0.5.0.0\*
>
> rm ..\ThirdParty\haskell_packages\doc\zlib-0.5.0.0\*
>
> I suspect most people haven't tripped over this as once something is installed
> they don't tend to install it again.
This looks like:
http://hackage.haskell.org/trac/hackage/ticket/454
But for every file not just .exe files. For .exe files Cabal does the
permission copying itself. I do not understand why it just started
occurring, since ghc-6.8 and 6.10 seem to have the same code for
copyFile and copyPermissions.
We'll need more help to understand and fix this one. I think the right
solution will be that we do not copy permissions at all but either set
permissions to precise values or do nothing and use defaults. On Unix we
have a similar issue with umasks.
Duncan
More information about the Libraries
mailing list