April 2008 - cabal-devel

[Hackage] #174: cabal-install tries to upgrade the base package
by Hackage 21 May '08

21 May '08

#174: cabal-install tries to upgrade the base package ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install | Version: 1.2.2.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.6 Platform: Linux | ----------------------------+----------------------------------------------- When using ghc-6.6.x, with some packages, cabal-install tries to upgrade the base package to satisfy dependnecies. This is obviously impossible. The dependency resolution mechanism needs to be taught this fact. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/174> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 7

[Hackage] #226: Cabal install should upgrade in the correct order.
by Hackage 21 May '08

21 May '08

#226: Cabal install should upgrade in the correct order. ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ---------------------------------+------------------------------------------ Also, `cabal upgrade package-name` should probably upgrade that packages and dependencies, but not other packages. Here was my session with darcs cabal-install 2008-01-31: {{{ $ cabal upgrade Upgrading the following packages: cgi-3001.1.5.2 hmatrix-0.2.0.0 pcre-light-0.3 regex-base-0.93.1 regex-compat-0.91 regex-posix-0.93.1 TypeCompose-0.3 xhtml-3000.0.2.2 zlib-0.4.0.2 Downloading 'cgi-3001.1.5.2'... [... cgi upgrades fine ...] Configuring regex-compat-0.91... setup: At least the following dependencies are missing: regex-base >=0.93, regex-posix >=0.93 Downloading 'TypeCompose-0.3'... Downloading 'xhtml-3000.0.2.2'... Downloading 'zlib-0.4.0.2'... cabal: Error: some packages failed to install: zlib-0.4.0.2 xhtml-3000.0.2.2 TypeCompose-0.3 regex-compat-0.91 regex-posix-0.93.1 regex-base-0.93.1 pcre-light-0.3 hmatrix-0.2.0.0 $ cabal upgrade regex-base Upgrading the following packages: hmatrix-0.2.0.0 pcre-light-0.3 regex-base-0.93.1 regex-compat-0.91 regex-posix-0.93.1 TypeCompose-0.3 xhtml-3000.0.2.2 zlib-0.4.0.2 'hmatrix-0.2.0.0' is cached. [... everything through TypeCompose upgrades fine ...] 'xhtml-3000.0.2.2' is cached. Configuring xhtml-3000.0.2.2... 'zlib-0.4.0.2' is cached. Configuring zlib-0.4.0.2... [... zlib upgrades fine ...] cabal: Error: some packages failed to install: xhtml-3000.0.2.2 $ cabal upgrade Upgrading the following packages: xhtml-3000.0.2.2 'xhtml-3000.0.2.2' is cached. Configuring xhtml-3000.0.2.2... [... succeeds ...] }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/226> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #214: Package security
by Hackage 21 May '08

21 May '08

#214: Package security ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: misc | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: project(> week) | Ghcversion: 6.8.2 Platform: | ------------------------------+--------------------------------------------- It'd be nice to avoid getting hacked by a trojaned package. This task is to: * survey the issue * consider the threats * see what solutions other systems use * consider the cost/benefit trade-offs in various security solutions * propose something -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/214> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

3 17

[Hackage] #260: cabal upgrade runs install on the current package instead of upgrading installed packages
by Hackage 11 May '08

11 May '08

#260: cabal upgrade runs install on the current package instead of upgrading installed packages ---------------------------------+------------------------------------------ Reporter: tibbe | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: Linux | ---------------------------------+------------------------------------------ I was very suprised when I tried to use cabal to upgrade my installed packages today: {{{ $ cabal upgrade cabal: No cabal file found. Please create a package description file <pkgname>.cabal }}} Looks like Cabal tries to do a build instead so I tried it in a directory with a .cabal file: {{{ $ cd hyena $ cabal upgrade Configuring hyena-0.1.0... Preprocessing library hyena-0.1.0... Preprocessing executables for hyena-0.1.0... Building hyena-0.1.0... ar: creating archive dist/build/libHShyena-0.1.0.a [5 of 7] Compiling Hyena.Logging ( Hyena/Logging.hs, dist/build/hello- world/hello-world-tmp/Hyena/Logging.o ) [6 of 7] Compiling Hyena.Server ( Hyena/Server.hs, dist/build/hello- world/hello-world-tmp/Hyena/Server.o ) [7 of 7] Compiling Main ( ./Hyena/HelloWorld.hs, dist/build /hello-world/hello-world-tmp/Main.o ) Linking dist/build/hello-world/hello-world ... Installing: /Users/tibell/.cabal/lib/hyena-0.1.0/ghc-6.8.2 Installing: /Users/tibell/.cabal/bin Registering hyena-0.1.0... Reading package info from "dist/installed-pkg-config" ... done. Saving old package config file... done. Writing new package config file... done. }}} Instead of upgrading my installed packages it installed ''this'' package! Here are Cabal and cabal-install versions: {{{ $ cabal --version cabal-install version 0.4.4 using version 1.3.7 of the Cabal library }}} I've synced from HEAD today. Here are the latest patches I'm using. Cabal: {{{ Wed Mar 12 21:39:47 CET 2008 Duncan Coutts <duncan(a)haskell.org> * Fix search dirs used for pre-processing executables }}} and for cabal-install: {{{ Wed Mar 12 14:53:35 CET 2008 Duncan Coutts <duncan(a)haskell.org> * Parse filepaths in the config file the same way as in .cabal files }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/260> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #271: The index page should link to a package, not a package version
by Hackage 10 May '08

10 May '08

#271: The index page should link to a package, not a package version --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: HackageDB website | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | --------------------------------+------------------------------------------- The index page (http://hackage.haskell.org/packages/archive/pkg-list.html) should link to packages (i.e. http://hackage.haskell.org/cgi-bin/hackage- scripts/package/haskell-src-exts), not particular package versions (http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src- exts-0.3.3). This will decrease teh number of people who pass around outdated URL's, as its rare people want a particular version of a package -- usually they want the most recent version. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/271> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

Specifying dependencies on Haskell code
by Duncan Coutts 01 May '08

01 May '08

All, In the initial discussions on a common architecture for building applications and libraries one of the goals was to reduce or eliminate untracked dependencies. The aim being that you could reliably deploy a package from one machine to another. We settled on a fairly traditional model, where one specifies the names and versions of packages of Haskell code. An obvious alternative model is embodied in ghc --make and in autoconf style systems where you look in the environment not for packages but rather for specific modules or functions. Both models have passionate advocates. There are of course advantages and disadvantages to each. Both models seem to get implemented as reactions having the other model inflicted on the author. For example the current Cabal model of package names and versions was a reaction to the perceived problem of untracked dependencies with the ghc --make system. One could see implementations such as searchpath and franchise as reactions in the opposite direction. The advantages and disadvantages of specifying dependencies on module names vs package names and versions are mostly inverses. Module name clashes between packages are problematic with one system and not a problem with the other. Moving modules between packages is not a problem for one system and a massive pain for the other. The fact is that both module name and package name + version are being used as proxies to represent some vague combination of required Haskell interface and implementation thereof. Sometimes people intend only to specify an interface and sometimes people really want to specify (partial) semantics (eg to require a version of something including some bug fix / semantic change). In this situation the package version is being used to specify an implementation as a proxy for semantics. Neither are very good ways of identifying an interface or implementation/semantics. Modules do move from one package to another without fundamentally changing. Modules do change interface and semantics without changing name. There is no guarantee about the relationship between a package's version and its interface or semantics though there are some conventions. Another view would be to try and identify the requirements about dependent code more accurately. For example to view modules as functors and look at what interface they require of the modules they import. Then we can say that they depend on any module that provides a superset of that interface. It doesn't help with semantics of course. Dependencies like these are not so compact and easy to write down. I don't have any point here exactly, except that there is no obvious solution. I guess I'd like to provoke a bit of a discussion on this, though hopefully not just rehashing known issues. In particular if people have any ideas about how we could improve either model to address their weak points then that'd be well worth discussing. For example the package versioning policy attempts to tighten the relationship between a package version and changes in its interface and semantics. It still does not help at all with modules moving between packages. Duncan

2 2

[Hackage] #268: cabal upload asks for a password in plain text
by Hackage 01 May '08

01 May '08

#268: cabal upload asks for a password in plain text ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- > > Cabal upload asks for your password in plain text. That one is > > security related - you are asking for someones password, and giving > > the appearance that you aren't overly fussed about keeping it secret. > > I'm happy to add that if anyone can figure out the code to do it. It's > presumably different on ANSI terminals and the Windows command console. getChar in a loop? You can always do: c <- getChar putChar '*' If you so feel like it. You can even use putStr "\b \b" to move back one character, even on Windows. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/268> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

patch applied (cabal): Change handling of bool command line args to allow an unset state
by Duncan Coutts 01 May '08

01 May '08

Tue Apr 29 13:11:23 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Change handling of bool command line args to allow an unset state For bool valued flags we were always producing the command line string corresponding to a false flag value, even if the flag was not set. For example we'd always get "--disable-shared". It is important for cabal-install to be able to take an empty set of flags, override a few flags and turn the flags back into command line strings without getting a lot of extra defaults. Partly this is because we have to work with older versions of the Cabal library command line which does not recognise the new options. M ./Distribution/Simple/Command.hs -6 +9 M ./Distribution/Simple/Setup.hs -2 +2 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080429201123-adfee-035dad7f…

2 2

hasLibs and hasExes honest reporting?
by Yaakov Nemoy 30 Apr '08

30 Apr '08

Hi List, First off, I want to say hi, as this is my first post. I'm trying to get some badly needed updates to cabal-rpm, so we can get more Haskell packages into Fedora. All of the following is with Cabal 1.2.3.0 and GHC 6.8.2 as packaged in Fedora 8. In the module Distribution.PackageDescription, there are four functions, hasExes, and hasLibs, as well as libModules and exeModules. These functions claim to do the obvious for a PackageDescription. The only problem I'm having is with packages like xmonad, which have both Executables and Libraries. In the case of xmobar, hasLibs returns False, and an empty list for libModules, but True and a list for hasExes and exeModules respectively. In the case of xmonad-contrib, the opposite is true, that is there are no Executables at all, but a bucket load of Libraries. In the case of xmonad, hasLibs returns True. but returns a nonempty list. hasExes returns True, and with the same nonempty list. I would expect the lists to be the same, as all the Modules listed therein are needed to compile the executable, and also to be linked with the user supplied config file. The only problem I see is with hasLibs itself. I heard something a while back that xmonad needs to be compiled twice, because this setup is considered an edge case in Cabal. Because xmonad is the reason why I'm working on getting Haskell packages into Fedora, I'm not sure I want to think of it that way. Is this a bug, or just a 'feature' I need to watch out for? Cheers, Yaakov Nemoy

3 5

patch applied (cabal-branches/cabal-1.4): Add help command as per ticket #272
by Duncan Coutts 30 Apr '08

30 Apr '08

Wed Apr 30 06:37:40 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Add help command as per ticket #272 "cabal help" behaves like "cabal --help" "cabal help cmd" behaves like "cabal cmd --help" Should still work with command line completion. M ./Distribution/Simple/Command.hs -15 +42 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/2008043013…

1 0