The installation instructions at the Stackage web site describe how to use it for one project.
Is there a way how to configure Stackage to be the default for all users and install packages globally available to them?
AFAIK cabal does not support a global config file. But even that won't help by itself because afaict, you can't disable configured remote-repos anyway.
So I see two approaches with obvious drawbacks.
Clean way for new users
Install a /etc/skel/.cabal/config file that will be copied to new user accounts. That won't help with older users though.
Hacky way for all users
Install a global alias (or shell script wrapper) with name cabal that calls cabal --remote-repo=hackage.haskell.org:http://www.stackage.org/lts.
Users can opt out by unaliasing cabal or using the real cabal executable when using a shell script.
Users will be utterly confused though, because cabal will tell users it uses hackage, when in fact it is using stackage.
Related
The current documentation of cabal shows a sandbox subcommand.
The respective page on github no longer contains the section on sandboxes.
I'm using cabal version 3.2.0.0, but the sandbox subcommand is absent. What is the correct way to manage sandboxes with cabal?
Apparently there's an overhaul going on with the documentation, there's mention of a Nix-style/new-/v2 commands but it's unclear to a noob what's the canonical way of using sandboxes with cabal.
They're no longer needed. The nix-style store does everything sandboxes did, but better. Just use use cabal build (cabal v2-build for pre-3.0 cabal's) and other cabal commands with impunity in a bare, sandbox-free directory.
Is it possible to set Options (http://nixos.org/nixos/options.html) just for a single nix-shell instead of defining them globally at /etc/nixos/configuration.nix?
Those options you are referring to are only meant for NixOS, which usually translate (in the background) to configuring systemd unit files and creating configurations files in /etc.
On the other hand, the nix-shell tool is part of Nix (the package manager) which can be used on any Linux distribution (alongside any other package manager), and also on the latest macOS / OS X.
Nix (the package manager) only installs binary packages, and does not configure them, like other linux package managers do. Something like how homebrew works.
To recap:
NixOS (nixos-*) commands use Nix to install and to configure binaries of packages.
Nix (nix-*) commands only install binaries of packages; you have to configure them yourself.
If you are running NixOS or any systemd-based Linux distro, there is a way to create systemd containers using the same NixOS options. Documentation on containers is avaliable here.
Now, before you start jumping into containers with Nix, please know that the nixos-container command is still a work in progress, and requires some knowledge of the Nix expression language. Nonetheless, any feedback is more than welcome, and Nix developers are actively working on improving it.
If you are only looking to configure certain packages (eg. Vim, weechat) to be used across you system, this is also possible for some of them, but currently also requires some knowledge of the Nix expression language. Let me know which packages you are interested in to configure, and I can tell you how hard it would be to do it.
Hope this helps you a bit.
I'm writing a program that requires LLVM, and thinking of using autotools to ship it on Linux, so from the user's viewpoint the process would look like the well-known ./configure && make && sudo make install.
With autotools, one normally relies on the system package manager to install dependencies. The problem is that, for whatever reason, this doesn't work with LLVM; on Ubuntu 14.04, apt-get thinks the latest version is 3.4, whereas a more recent version would actually be needed. Thus, I need to supply a script to download and build LLVM first (a local copy thereof, not interfering with any older version that might be on the system), a process which takes a few hours.
The most obvious place to put this process is at the start of configure. Is this considered normal and reasonable? Or is there a convention that configure should only contain the things autotools normally puts in it, and installing dependencies should be another script that the user runs first and separately? In the latter case, is there a convention regarding what that separate script should be called?
Don't install anything during configure. The scripts name is "configure" not "install-dependencies".
Write a configure check, and if llvm is missing, Give the user an explanation how to install it. If necessary provide a separate script to download llvm.
It is good practice to run configure (and make) as normal unprivileged user and not as root. So you may not even have permissions to install anything. You would have to check if "sudo" is installed, etc.
It may also happen that the system the user is installing has no network connectivity (firewall etc.), so your download will fail.
When I have a sandbox, it seems cabal install ignores packages in $HOME/.ghc/x86_64-linux-7.8.4/package.conf.d.
How can I configure the sandbox such that these packages become visible?
I am seeing a vague reference to --package-db=db in https://www.haskell.org/cabal/users-guide/installing-packages.html#sandboxes-advanced-usage
but I understand neither how nor when to use it. (with sandbox init? configure? install? none seems to work - none gives any error message either.)
I know about add-source but my question refers to installed packages.
The whole point of the sandbox is that it ignores your local package database.
If you want to share installations across many sandboxes, you may install to the global database; but then you should be very careful, as fixing the badness of a broken package is much more difficult. Keep it to really core packages that you expect to be widely shared across many, many projects -- not just the half dozen you're stressing out about right now for your job.
Alternately, you may share one sandbox between the builds of many packages; simply set the CABAL_SANDBOX_CONFIG variable to an absolute path pointing to the appropriate cabal.sandbox.config file. This is significantly safer, and much more flexible, as you can choose how widely your installed packages are shared (and in bad cases, simply nuke the sandbox and start over).
Here is something you can try - copy (or symlink) the files from ~/.ghc/{arch-os-ghc-version}/package.conf.d to the sandbox's {arch-os-ghc-version}-packages.conf.d directory.
There is a question about the package.cache file. The following procedure seems to be a safe way to proceed:
Start with an empty sandbox
Copy the package.conf.d files from ~/.ghc to the sandbox (including package.cache)
Add packages to the sandbox via cabal install --only-dependencies
I don't know if the package.cache file is required or if there is a way to rebuild it.
One disadvantage is that cabal install --only-deps seems to reinstall broken packages in the sandbox even if they are not required by your application. Maybe there is work-around for this.
I have a libfoo-devel rpm that I can create, using the trick to override _topdir. Now I want to build a package "bar" which has a BuildRequires 'libfoo-devel". I can't seem to find the Right Way to get access to the contents of libfoo-devel without having to install it on the build host. How should I be doing it?
EDIT:
My build and target distros are both SuSE.
I prefer solutions that don't require mock, since I believe SuSE does not include it in its stock repo.
Subsequent EDIT:
I believe that the answer I seek is in the build package. Perhaps it's SuSE's answer to mock? Or it's the distributed version of the oBS service?
DESCRIPTION
build is a tool to build SuSE Linux
RPMs in a safe and clean way. build
will install a minimal SuSE Linux as
build system into some directory and
will chroot to this system to compile
the package. This way you don't risk
to corrupt your working system (due to
a broken spec file for example), even
if the package does not use BuildRoot.
build searches the spec file for a
BuildRequires: line; if such a line is
found, all the specified rpms are
installed. Otherwise a selection of
default packages are used. Note that
build doesn't automatically resolve
missing dependencies, so the specified
rpms have to be sufficient for the
build.
Note that if you really don't need libfoo-devel installed to build package bar the most sensible alternative would be to remove libfoo-devel from the BuildRequires directive (and maybe put the requirement where it belongs).
However, if you cannot do that for some reason, create a "development" rpm database. Basically it involves using rpm --initdb --root /path/to/fake/root. Then populate it with all of the "target packages" of your standard distro installation.
That's a lot of rpm --install --root /path/to/fake/root --justdb package-name.rpm commands, but maybe you can figure out a way to copy over your /var/lib/rpm/* database files and use those as a starting point. Once you have the alternative rpm database, you can fake the installation of the libfoo-devel package with a --justdb option. Then you'll be home free on the actual rpm build.
If neither mock nor the openSUSE Build Service are a viable choice then you will have to buckle down and install the package, either directly or in a chroot; the package provides files that the SRPM packager has decided are required to build, and hence is in the BuildRequires tag.