Ticket #578 (new enhancement)

Opened 4 years ago

Last modified 17 months ago

Allow installation of distro packages

Reported by: bos Owned by:
Priority: normal Milestone: _|_
Component: cabal-install tool Version:
Severity: normal Keywords:
Cc: nomeata Difficulty: project(> week)
GHC Version: Platform:

Description

It would be very nice indeed if cabal-install could be taught how to install a distro's version of a package. This could amount to simply asking a shell script if the package is available and can be installed, before proceeding with the usual Cabal installation machinery.

Change History

  Changed 4 years ago by duncan

  • difficulty changed from unknown to project(> week)
  • version 1.6.0.1 deleted
  • milestone set to _|_

I think this would be extremely difficult to do sanely and correctly.

For one thing there's the permissions issue. It's only any good if the user is root so that they can install system packages. We would also need to know that the compiler the user is using is actually provided by a distro package.

The main issue is that asking if a version of a Haskell package is available as a distro package is not nearly enough information for cabal-install to construct an installation plan.

We do not know if the distro package provides the same thing as what our install plan calls for. We can ask the system-specific script if a distro package for foo-1.0 is available, but if the distro built foo-1.0 against bar-1.0 but our install plan called for it to use bar-2.0 then we're stuffed (or we need to replan everything and there is no guarantee that the alternative plan exists).

It would need integration on a rather more intimate level. We would need to know the complete dependency info between the distro packages (at least between those providing Haskell packages). There's the added complication that distro packages will often bundle several Haskell packages (like ghc + core packages).

follow-up: ↓ 3   Changed 4 years ago by nomeata

  • cc nomeata added

What if information from /var/lib/ghc-6.10.4/./package.conf would be available even for yet-uninstalled distro packages, e.g. the complete value of InstalledPackageInfo?. Would the task them become handleable?

in reply to: ↑ 2 ; follow-up: ↓ 4   Changed 4 years ago by duncan

Replying to nomeata:

What if information from /var/lib/ghc-6.10.4/./package.conf would be available even for yet-uninstalled distro packages, e.g. the complete value of InstalledPackageInfo?. Would the task them become handleable?

Yes. That would be more than sufficient. If that's easiest then fine, otherwise the minimum required is the complete dependency graph of exact package versions.

in reply to: ↑ 3   Changed 4 years ago by nomeata

Replying to duncan:

Yes. That would be more than sufficient. If that's easiest then fine, otherwise the minimum required is the complete dependency graph of exact package versions.

We have the data readily available inside the packages, but it will be non-trivial to export them in a way that makes them available for non-installed packages. I’ll bring it up on debian-haskell, maybe someone has a ingenious idea. I don’t :-)

follow-up: ↓ 6   Changed 4 years ago by duncan

The other aspect of the problem of course is the permissions issue. Users are typically running cabal under their normal user account. Should we attempt to elevate privileges and if so when and how?

We already support a --root-cmd=sudo flag which we use with global installs performed as the user so that we build as the user and do the install step as root.

in reply to: ↑ 5 ; follow-up: ↓ 8   Changed 4 years ago by nomeata

Replying to duncan:

The other aspect of the problem of course is the permissions issue. Users are typically running cabal under their normal user account. Should we attempt to elevate privileges and if so when and how? We already support a --root-cmd=sudo flag which we use with global installs performed as the user so that we build as the user and do the install step as root.

From my point of view, I’d already be satisfied if cabal would say "The following required packages are also available from your distribution and it is recommended to install them before continuing: libghc6-a-dev libghc6-b-dev. Do you want to abort now? [Y,n]".

follow-up: ↓ 9   Changed 4 years ago by bos

Ditto to what nomeata said. cabal doesn't need to offer any platform-specific machinery of substance here. It would be sufficient for it to define an interface to maybe two shell scripts:

* one which would query "what is, or could be, installed, with complete dependency information?" * another which would either perform the installation or abort, and actually deal with the details of authorisation and privilege escalation and so on

in reply to: ↑ 6   Changed 4 years ago by duncan

Replying to nomeata:

From my point of view, I’d already be satisfied if cabal would say "The following required packages are also available from your distribution and it is recommended to install them before continuing: libghc6-a-dev libghc6-b-dev. Do you want to abort now? [Y,n]".

Unlike apt-get, most cabal commands are not interactive. We prefer to go with "Do the right thing". For this issue, surely either the right thing is to install the system package or it's not. It's not going to vary on a per-package basis. At most it should be a config file preference. Though what the default should be I don't know.

in reply to: ↑ 7   Changed 4 years ago by duncan

Replying to bos:

Ditto to what nomeata said. cabal doesn't need to offer any platform-specific machinery of substance here. It would be sufficient for it to define an interface to maybe two shell scripts:

Yes, that's fair enough. I like the idea of the query interface just being another installed package database in the ghc-pkg format. For the actual install it'd be fine to call a pre-configured system-supplied script that would handle the authentication.

The interface would have to handle multiple packages in one go and the script would have to map Haskell package names to native ones. If that script fails then the whole shebang should fail.

Note: See TracTickets for help on using tickets.