“The magic in CheckInstall is that it learns everything your new app or package will add to your system, and then creates a binary installable package geared to the package manager you use, whether that be Slackware, RPM, or Debian. Optionally, it will also install the newly created package. But whether you install then or later, when the time comes that you want to remove the package from your system, all you need to do is run the appropriate command for your package manager.”
The best part of CheckInstall isn’t simply package tracking, as there are other ways to do that (Source Installer). The best part is having a binary that you can then use on all your other boxes (provided you use the same distro on your other boxes).
I actually maintain my own repository for all my favorite apps that aren’t easy to find available binaries for. Then I created a simple metapackage to install all my favorite apps, so now anytime I want to do a new install for myself or any of my friends I just add an extra line to the sources.list, do a quick update and run:
sudo apt-get install my-favorite-apps
Many of the packages in my repository came from running CheckInstall. Kudos to Felipe Eduardo Sánchez Díaz Durán for creating such a great app
There is another simple way you can create an installable/uninstallable package for your distribution, out of software compiled with Makefiles.
Run the usual steps to compile the software, which generally is ./configure and make. Then run
make DESTDIR=/tmp/pkg install
This will copy all the binary files to somewhere like /tmp/pkg/usr/local
Now what you need to do is chown this directory to root (chown -R root:root /tmp/pkg) and convert it to a package using a tool for your distribution (like makepkg on slackware).
Some Makefiles don’t use the DESTDIR variable for setting the root for the installed files, so in that case it may take some common sense and a look at the Makefile
Pkg_trackinst utility
http://www.freshports.org/sysutils/pkg_trackinst/
does something similar on FreeBSD.
Does it work with Fedora Core yet?
Hopefully this will allow projects to distribute binaries in many formats all at once for each release.
Let’s hope Checkinstall continues to mature, it’s already a great tool, but it still needs some extra polishing. For example, packages made with the latest version (granted the latest version was/is in beta the last time I checked) experience frequent errors saying the same applications can’t install in a ‘man’ directory with some overwrite error (but I should be reporting this to the author and not a news site, I know, I know).
Three cheers for Checkinstall!
Tried CheckInstall recently for some apps from kde-apps.org At lest 2 installations were botched. (klocate, basket, or something of that kind.) Had to go back to –prefix=/some/fake/rootfolder and build the package using distro-specific tools.
Moral – one strange move in the make script > no go.
what linux realy needs is for a way to do this in a simple gui. like say drop the file onto a icon or into a gui and it will run along and in the end install it into the system.
i wonder tho, what happens to dependencys?
most likely dependencys will break this at the ./configure or make stage so this isnt a tool to allow people fresh from windows to install source-balls without freaking out and going back to windows.
People fresh from Windows shouldn’t be installing from source in the first place.
Checkinstall is great for Linux users of Intermediate level, who like to install stuff not available for their distro while still being able to track and remove the compiled pacakge.
maybe so, but some of the development in linux happens so fast that by the time its out there in distro form its allready old. or maybe you need to get that shiny new gizmo working and noone have made a available a package for its support.
this is realy one of the problems of linux. your stuff never comes with the needed software on a cd, easy to install…
its a chicken and egg thing…
Actually, if you run a “bleeding-edge” distro such as Mandrake Cooker, it doesn’t take long for packages to be available. And if you need a shiny new gizmo for which there isn’t a package yet, then you can install it from source and then use checkinstall to manage it. It’s not hard, in fact it’s pretty simple. (Although, to be fair, if there is a driver for the shiny new gizmo it will be in the kernel, not in a package.)
this is realy one of the problems of linux. your stuff never comes with the needed software on a cd, easy to install.
I’m sorry but this is FUD. Pretty much all you’ll need when installing Linux is on the CD, the only exception being proprietary drivers. The rest is just an internet connection away.
The problem is that you’re looking at this with a Windows mindset, i.e. you should always run the very latest version of an app. With Linux, you should run the supported version for your distro.
This is the same as running unsupported beta versions on Windows: it might work, but it’s not Windows fault if it doesn’t. The same thing applies here: you can install unsupported “unstable” software if you want, but it’s not suggested for novice users.
I’m sorry but this is FUD. Pretty much all you’ll need when installing Linux is on the CD, the only exception being proprietary drivers. The rest is just an internet connection away.
Your definition of FUD is comical, and your experience with the plethora of Linux distros must be limited if you believe the rest is just an Internet connection away for many users – especially without compiling from source, which was the parent’s point in the first place. Let’s face it, most home users running Linux today aren’t typical users but enthusiasts, even if they don’t have advanced skills. Enthusiasts want to run new apps which might not be packaged for their particular distro for months and months. Maybe you think that’s stupid, but they do and that isn’t going to change.
Solutions? Learn how to compile from source if you’re comfortable with that. Use one of the distros which do have a very broad and up-to-date package base so you won’t have to wait long (Debian or Debian-derived distros being a great example). Wait for something like Autopackage to become more widespread and supported (even as a lifelong Unix guy, it shocks me how many people don’t understand the absolutely essential utility of something like autopackage for Joe User, not to mention upstream alpha and beta testing).
The problem is that you’re looking at this with a Windows mindset, i.e. you should always run the very latest version of an app. With Linux, you should run the supported version for your distro.
This is great advice for Joe Enterprise. But it’s useless advice that will be ignored by Joe Enthusiast, and right now Joe Desktop Linux = Joe Enthusiast. Let’s adapt to reality and stop insisting that reality adapt to us, because it just ain’t gonna happen.
Replying to self here…
Use one of the distros which do have a very broad and up-to-date package base so you won’t have to wait long (Debian or Debian-derived distros being a great example).
To clarify, I’m talking about sid packages here. Stable gives you the wide base but probably not very up-to-date, if the past is any guide. Alternatives include Ubuntu (sid based), Gentoo if you’re not source-wary, Fedora’s package base is getting a lot richer… blah blah blah.
“Your definition of FUD is comical, and your experience with the plethora of Linux distros must be limited if you believe the rest is just an Internet connection away for many users – especially without compiling from source, which was the parent’s point in the first place.”
Tell us then, besides proprietary software, or codecs with associated patents (a problem if no free equivalents exist), what else isn’t or can’t be part of a distribution’s repository (on CD and in the internet), that they would need to go and compile?
“Let’s face it, most home users running Linux today aren’t typical users but enthusiasts, even if they don’t have advanced skills. Enthusiasts want to run new apps which might not be packaged for their particular distro for months and months. Maybe you think that’s stupid, but they do and that isn’t going to change.”
No, it’s not going to change, just as it is not going to change the fact that a single-individual maintained system of installed software, one that doesn’t have advanced skills, is a step away for breakage, instability, and other bad symptoms whose causes can range from incompatibilites between software, sub-reviewed free software, to non-publicly-reviewed closed-source proprietary software. This problem was tackled by distributions years ago, giving us today software that has been properly tested, reviewed and tuned to work fine with each other, and with the overall system.
For development versions, where developers want feeback from novice users, or a user needs/wants a newer version of a program, then there are many options: a distritbution package, klik, autopackage, pre-compiled binaries, with pre-compiled binaries if necessary, etc.
“”The problem is that you’re looking at this with a Windows mindset, i.e. you should always run the very latest version of an app. With Linux, you should run the supported version for your distro.”
This is great advice for Joe Enterprise. But it’s useless advice that will be ignored by Joe Enthusiast, and right now Joe Desktop Linux = Joe Enthusiast. ”
Joe Enthusiast, in matters of the kind of system he’ll have on his computer, can really choose whether he prefers to:
– Get well tested and supported software
– Live on the bleeding edge, expect breakage
Or he can be enthusiastic enough to learn some more about gnu/linux, and learn about compiling.
I think the tools that exist now (mentioned above) can, single or in conjunction, handle very well these two situations.
“Let’s adapt to reality and stop insisting that reality adapt to us, because it just ain’t gonna happen.”
Reality is not a monolith. It is shaped and constructed by us all.
I’m not going to quote the parents’ argument, but I will make some statements:
Binary distributions are great for most users. There’s seldom anything really missing from their package repositories, and if there is, the user is blissfully unaware.
For these so-called enthusiast macho-men who yearn to live on the bleeding edge and cry when things break, there are plenty of options: Debian Sid, Mandriva Cooker, Fedora Core’s equivalent, Gentoo unstable…
For those who need a package that isn’t in the repositories at all, there are three options: use one of the various tools to convert one package format into another, compile it from source (possibly with checkinstall), or submit a request to your distributor to include your package.
For those who want a complete source-based system with dependency resolution and other bells and whistles, try Gentoo. You’ll have some ebuilds fail from time to time, but it’s remarkably good.
For those who want a binary distribution, but also want to be able to compile packages from source (to customize the build of an existing package or build a new package), then Arch is pretty much your best bet. It doesn’t have nearly as many packages as Debian or as many PKGBUILDs as Gentoo has ebuilds, but it is very easy to create your own packages. Unlike checkinstall, PKGBUILD/makepkg resolves dependencies and approaches the functionality of Gentoo’s Portage.
Like I said previously, it is futile to try to support this enthusiast crowd that does nothing but make demands. They can accept the software choices available in their distribution’s repositories, live on the bleeding edge, or learn how to help themselves. If you are such an enthusiast, then you can probably devote some time to creating a package for your must-have software the right way… not by using checkinstall.
Your definition of FUD is comical, and your experience with the plethora of Linux distros must be limited if you believe the rest is just an Internet connection away for many users – especially without compiling from source, which was the parent’s point in the first place. Let’s face it, most home users running Linux today aren’t typical users but enthusiasts, even if they don’t have advanced skills. Enthusiasts want to run new apps which might not be packaged for their particular distro for months and months. Maybe you think that’s stupid, but they do and that isn’t going to change.
My definition of FUD is just fine, as the fact that bleeding-edge packages are not available the minute that the source is updated was said to be “one of the problems” of Linux.
The fact is I don’t think that wanting to run the very very last version of a program before binaries are available are stupid (I don’t know where you got that idea, because I do it often myself). However, I think that compiling apps from source is perfectly acceptable in that context.
Solutions? Learn how to compile from source if you’re comfortable with that. Use one of the distros which do have a very broad and up-to-date package base so you won’t have to wait long (Debian or Debian-derived distros being a great example).
Which is exactly what I said. Are you legit or just trying to pick a fight?
Wait for something like Autopackage to become more widespread and supported (even as a lifelong Unix guy, it shocks me how many people don’t understand the absolutely essential utility of something like autopackage for Joe User, not to mention upstream alpha and beta testing).
Wait, are you talking about “Joe User” or “Joe Enthusiast”? Because despite what you claim, they aren’t the same target audience at all.
This is great advice for Joe Enterprise. But it’s useless advice that will be ignored by Joe Enthusiast, and right now Joe Desktop Linux = Joe Enthusiast. Let’s adapt to reality and stop insisting that reality adapt to us, because it just ain’t gonna happen.
There is no “one” Joe Desktop Linux. There are people who just want their computer to run and be stable, there are those who like to tinker around. The latter will have no problems compiling from source (heck, they might even run Gentoo), and for those who use RPM or Debian-based distros, checkinstall is a great tool.
Let’s drop the idea that “enthusiasts” desperately want a GUI tool to install from source, because that’s simply not true. If it was, there’d be one already (there is, actually: Arkollon, used by the Apollon software and adapted for XFce, IIRC).
but it’s not suggested for novice users.
Unless one wants to stay novice forever.I have screwed my system countless of times testing ,trying out new software.If the particular branch didn’t have what i wanted i just compiled the app from source.After all it’s a kernel plus userland now is it?
Most of the binairy distros would benefit from checkinstall.
On Gentoo it couldn’t hurt but i think a emerge –unmerge would do well too.
So you want source-based package management on a binary distribution? I don’t know if there’s a huge demand for this, but a few of you have raised some good points about “enthusiasts” who want to run the latest versions of everything but don’t have such advanced skills.
Bottom line: this checkinstall thing seems great until you find that configure doesn’t always succeed. You might be missing dependencies, have your kernel configured incorrectly, or any number of package-specific problems.
When I first clicked on the link, I figured that checkinstall would uncompress the tarball, cd into it, run the configure script, determine and install any missing dependencies using the selected package manager, make, call the appropriate package creation utility, and optionally install the package. I determined that this script would be trivial except for deriving dependencies from the configure script. Well, checkinstall doesn’t even do this much, so it is pretty much a simple automation of a few tasks. It does a fakeroot install and seems to use its own simplistic package creator instead of the ones found on all of the target distributions.
checkinstall doesn’t work for the same reason that Gentoo doesn’t have a script for autogenerating ebuilds and Arch doesn’t have a script for autogenerating PKGBUILDs. Source-backed package management is a tough problem, and while Gentoo has made it fairly easy from the user’s perspective, and Arch has made it fairly easy from the developer’s perspective, none have been able to make it truly automagical from both angles.
I don’t know that much about autotools, unfortunately. But this source-based automation can only work if the configure scripts list runtime and compile-time dependencies in a more-or-less standard way. Even then, it is questionable whether the naming of dependency packages and/or virtuals is consistent with the native package manager, or if the native repositories can provide the missing dependencies.
In the defense of autotools and the overall GNU-style build environment/toolchain, it is the superlative in this area. On what other platform does ./configure && make && make install (or it’s equivalent) work so much of the time? I’ve been working closely with the AIX build environment for a while now, and comparatively it’s a complete mess. If there’s any system on which one can perfect source-based package management, it’s GNU. But it’s a very difficult problem.
To all those enthusiasts who want the latest packages, but they aren’t in the <your distro here> repositories… checkinstall seems like a halfway decent attempt to automate the best-case scenario of source-based package management. If something goes wrong, and you can’t figure out why, then please don’t consider this a shortcoming of free software. IMHO the development community devotes too much attention to this leecher segment of the userbase anyway.
Oh, and even if configure exits successfully, make might still fail. On Gentoo, compilation bugs are the most common cause for an ebuild to fail, and they usually relate to a library version dependency that isn’t checked in configure and wasn’t addressed by the author of the ebuild.
Even when ebuild developers carefully list dependencies, create source patches, use custom configure/make flags, create links, rename binaries/libraries, and other things to make the build/install successful, some configurations might not be so happy.
Then we have to worry about more obscure side effects. Maybe installing a package requires adding/removing a service to/from the default runlevel. Maybe this package is intended to replace another package that might already be installed on the system. Maybe this package cannot be installed alongside a package that might already be installed on the system. Maybe installing this package requires the modification of another package’s configuration file.
Checkinstall is just a drop in the bucket. It doesn’t compare to Portage or Pacman, and even these systems aren’t perfect solutions.