On Monday 09 March 2009 01:26:37 pm Don Stewart wrote:

lists:

...

Hi folks,

I've got an application to release. I'm releasing the source, but I also wanted to release binary versions for people that don't have GHC. I developed on Windows, so making a Windows executable was simple. I also have access to an Ubuntu Linux box, on which I can easily build and test my app.

But, I'm a bit confused about how to release binaries for Linux. It's not so simple as on Windows. Or, maybe it is but I don't know it. What do people recommend as a way of distributing Linux binaries? I tried to make a Debian package and couldn't figure it out, but maybe that's overkill. GHC itself has some kind of tarball for the binary distributions, one for Debian and one for Red Hat. How would I make such a package and what would go into it? There's only one executable, so it shouldn't be too complicated.

You could make a .cabal package for it, and use that to construct a binary tar.gz bundle that's installable.

Duncan, is there a cabal binary-dist?

This seems like the best way to release it to me. Individual distros can package cabalised source tarballs as they choose; any typical user can cabal install the package. Regards, -- Conrad Meyer

Thanks folks for your replies. I did learn, from your e-mails and from the cabal documentation (example 9 on page http://www.haskell.org/cabal/release/cabal-latest/doc/users-guide/builders.h...), how to build a tarball with an executable and LICENSE file, via cabal copy. It would have been nice to include the documentation (user's guide) as well, but I don't know how to get cabal copy to put that into the bundle. Unfortunately, I don't feel it's of great use to the end user. Now they have a tarball with paths like /usr/local/bin/vintbas and /usr/local/share/doc/vintage-basic-1.0/LICENSE.txt. Untarring it gives a warning and strips the leading /, so it won't untar in root unless you CD to root first. And of course you have to have root access to do that. If you want to install it in your user dir, you'll have to make a substitution for the paths. You suggested I write my own install script. But certainly this is a common situation, and someone has made a generic install script for this sort of thing? As I've said I tried to make a Debian package, folowing two different cabal-to-debian instructions, and neither one worked. If it is a hurdle for me, I can imagine a lot of people are getting frustrated at trying to distribute their binaries on Linux. - Lyle

Lyle Kopnicky wrote:

If it is a hurdle for me, I can imagine a lot of people are getting frustrated at trying to distribute their binaries on Linux.

I don't think so. Developers usually just don't, and the distribution packagers seem to enjoy their specific messes... otherwise, they wouldn't package, or rewrite their package management. OTOH, as a user I utterly dislike things like loki installers, or, even worse, some rpm for some random RedHat version as the only available download. If you really, really think that I'd like to use a binary package, and want to make me happy, make a tarball that fits into /opt, with a layout like foo/bin/foo-bin foo/bin/foo foo/share/data.foo foo/README.foo , foo/bin/foo being a shell script containing some magic to set FOO_DATA_DIR [1] to some value and then calls foo-bin, passing all command line options. The simpler the better, I rather hardcode paths according to my install than read through 300 lines of shell code. This, of course, isn't at all preferable to providing, in my case, a single .ebuild with build instructions and either get it included in the gentoo repository, or provide an overlay (and get that included in the overlay list) In a project, you usually either a) have someone who does all the packaging for major distros (which is a cool thing to do if you can't code yourself and don't want to be stuck with writing documentation), b) have each of the developers do packages for the distro they're using c) are lucky enough to be big (or important) enough so that distro package maintainers do the work for you. In either case, a source tarball is, and always will be, the most important thing to provide and the basis on which every other effort is built. If somebody is complaining that you're not providing more, recruit that somebody. In short: Just do a source tarball and don't worry about the rest. In the haskell case, just do a cabalised repo or tarball, preferably get it onto hackage, and don't worry about the rest. There are tools that automagically generate distribution packages from that. [1] and LD_LIBRARY_PATH and LD_PRELOAD -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

Thanks, folks. I have decided for now just to release a tarball with an executable and some docs, that can be expanded where the user deems appropriate. I'll try a static link if people are having problems with it. - Lyle