Allow installation of distro packages #571

Closed
bos opened this Issue May 24, 2012 · 11 comments

Projects

None yet

3 participants

@bos
Contributor
bos commented May 24, 2012

(Imported from Trac #578, reported by @bos on 2009-08-28)

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.

@bos
Contributor
bos commented May 24, 2012

(Imported comment by @dcoutts on 2009-08-28)

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).

@bos
Contributor
bos commented May 24, 2012

(Imported comment by @nomeata on 2009-08-28)

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?

@bos
Contributor
bos commented May 24, 2012

(Imported comment by @dcoutts on 2009-09-23)

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.

@bos
Contributor
bos commented May 24, 2012

(Imported comment by @nomeata on 2009-09-23)

Replying to @dcoutts:

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 :-)

@bos
Contributor
bos commented May 24, 2012

(Imported comment by @dcoutts on 2009-09-23)

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.

@bos
Contributor
bos commented May 24, 2012

(Imported comment by @nomeata on 2009-09-23)

Replying to @dcoutts:

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]".

@bos
Contributor
bos commented May 24, 2012

(Imported comment by @bos on 2009-09-23)

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
@bos
Contributor
bos commented May 24, 2012

(Imported comment by @dcoutts on 2009-09-23)

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.

@bos
Contributor
bos commented May 24, 2012

(Imported comment by @dcoutts on 2009-09-23)

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.

@tibbe
Member
tibbe commented May 15, 2014

Closing as there's been no activity in years.

We're cleaning up the bug tracker to make it useful again and are thus closing bugs that haven't seen any activity in a long time. Please re-open (or file a new bug) if the problem reappears.

@tibbe tibbe closed this May 15, 2014
@mietek
Contributor
mietek commented Jan 24, 2015

Halcyon supports declaring and automatically installing native OS packages for use at build-time with the HALCYON_SANDBOX_EXTRA_OS_PACKAGES option.

Similarly, you can use HALCYON_EXTRA_OS_PACKAGES to declare native OS packages to be installed for use at run-time.

See Haskell Language for an example of declaring libicu as a dependency.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment