Discussion:
uninstalling self-compiled software
Robin Paulson
2011-01-26 23:01:26 UTC
Permalink
this seems like a really dim question, but i can't begin to think of
how i might do it.

let's say i download a package in source form, and then use configure,
make, make install to install it. how do i uninstall it? it's not in
deb/rpm/whatever form, so i can't use apt/the red hat thingy to remove
it

deleting the files seems clumsy and ignores undoing any scripted steps
carried out during the install

what if i installed a kernel - is it as simple as editing the grub cfg files?

cheers
--
robin

http://tangleball.org.nz/ - Auckland's Creative Space
http://bumblepuppy.org/blog/

_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug
Dan Richardson
2011-01-26 23:05:53 UTC
Permalink
Errr "make uninstall" ?

Yay - first NZLUG posting (long time lurker!)

Cheers
Post by Robin Paulson
this seems like a really dim question, but i can't begin to think of
how i might do it.
let's say i download a package in source form, and then use configure,
make, make install to install it. how do i uninstall it? it's not in
deb/rpm/whatever form, so i can't use apt/the red hat thingy to remove
it
deleting the files seems clumsy and ignores undoing any scripted steps
carried out during the install
what if i installed a kernel - is it as simple as editing the grub cfg files?
cheers
--
robin
http://tangleball.org.nz/ - Auckland's Creative Space
http://bumblepuppy.org/blog/
_______________________________________________
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug
_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug
Dan Richardson
2011-01-26 23:07:52 UTC
Permalink
Oh, if "make uninstall" does't work, most likely it isn't defined in the
Makefile and will need to be removed by hand.

Cheers.
Post by Dan Richardson
Errr "make uninstall" ?
Yay - first NZLUG posting (long time lurker!)
Cheers
Post by Robin Paulson
this seems like a really dim question, but i can't begin to think of
how i might do it.
let's say i download a package in source form, and then use configure,
make, make install to install it. how do i uninstall it? it's not in
deb/rpm/whatever form, so i can't use apt/the red hat thingy to remove
it
deleting the files seems clumsy and ignores undoing any scripted steps
carried out during the install
what if i installed a kernel - is it as simple as editing the grub cfg files?
cheers
--
robin
http://tangleball.org.nz/ - Auckland's Creative Space
http://bumblepuppy.org/blog/
_______________________________________________
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug
_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug
Nick Rout
2011-01-26 23:14:58 UTC
Permalink
Which is why make checkinstall is such a good idea.
Post by Dan Richardson
Oh, if "make uninstall" does't work, most likely it isn't defined in the
Makefile and will need to be removed by hand.
Cheers.
Post by Dan Richardson
Errr "make uninstall" ?
Yay - first NZLUG posting (long time lurker!)
Cheers
Post by Robin Paulson
this seems like a really dim question, but i can't begin to think of
how i might do it.
let's say i download a package in source form, and then use configure,
make, make install to install it. how do i uninstall it? it's not in
deb/rpm/whatever form, so i can't use apt/the red hat thingy to remove
it
deleting the files seems clumsy and ignores undoing any scripted steps
carried out during the install
what if i installed a kernel - is it as simple as editing the grub cfg files?
cheers
--
robin
http://tangleball.org.nz/ - Auckland's Creative Space
http://bumblepuppy.org/blog/
_______________________________________________
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug
_______________________________________________
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug
_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug
Robin Paulson
2011-01-26 23:27:42 UTC
Permalink
Post by Nick Rout
Which is why make checkinstall is such a good idea.
right. at install time, instead of make install?
Post by Nick Rout
Post by Dan Richardson
Errr "make uninstall" ?
ha, i never knew that existed
--
robin

http://tangleball.org.nz/ - Auckland's Creative Space
http://bumblepuppy.org/blog/

_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug
Mark Foster
2011-01-26 23:29:50 UTC
Permalink
Post by Robin Paulson
Post by Dan Richardson
Errr "make uninstall" ?
ha, i never knew that existed
Neither did I. I think that's a worthy first-post, thanks Dan! :)



_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug
Nevyn
2011-01-26 23:36:17 UTC
Permalink
Post by Mark Foster
Post by Robin Paulson
Post by Dan Richardson
Errr "make uninstall" ?
ha, i never knew that existed
Neither did I. I think that's a worthy first-post, thanks Dan! :)
It only seems to exist "some" of the time. Who would ever want to
uninstall it? ;)

Regards,
Nevyn
http://nevsramblings.blogspot.com/

_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug
Nick Rout
2011-01-27 00:33:40 UTC
Permalink
Post by Robin Paulson
Post by Nick Rout
Which is why make checkinstall is such a good idea.
right. at install time, instead of make install?
Yes if I recall correctly
Post by Robin Paulson
Post by Nick Rout
Post by Dan Richardson
Errr "make uninstall" ?
ha, i never knew that existed
sometimes it does, sometimes it doesn't. Depends who wrote the makefile.
Post by Robin Paulson
--
robin
http://tangleball.org.nz/ - Auckland's Creative Space
http://bumblepuppy.org/blog/
_______________________________________________
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug
_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug
Daniel Pittman
2011-01-27 04:08:00 UTC
Permalink
Post by Nick Rout
Post by Robin Paulson
Post by Nick Rout
Which is why make checkinstall is such a good idea.
right. at install time, instead of make install?
Yes if I recall correctly
Indeed so. An alternative, from the days before anyone had good package
management is to install every package into a dedicated tree, and use a
symlink farm to expose it.

GNU Stow is one (but hardly the only) implementation of this idea.
Basically, throw the "foo" package under /usr/local/packages/foo/1.0/...

Then link the binaries into /usr/local/bin for ease of use; now rm -rf is
your uninstall process. This model even does versioning and rollback.

Regards,
Daniel
--
Puppet Labs Developer – http://puppetlabs.com
Daniel Pittman <***@rimspace.net>
Contact me via gtalk, email, or phone: +1 (503) 893-2285
Sent from a mobile device; please forgive brevity and typos.
_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug
Andrew Simpson
2011-01-27 04:37:26 UTC
Permalink
On Thu, 27 Jan 2011 12:01:26 +1300
Post by Robin Paulson
let's say i download a package in source form, and then use configure,
make, make install to install it. how do i uninstall it? it's not in
deb/rpm/whatever form, so i can't use apt/the red hat thingy to remove
it
deleting the files seems clumsy and ignores undoing any scripted steps
carried out during the install
It's good to get into the habit of putting self compiled binaries (and
their libraries) into /usr/local. I find 'make install' without control
has a terrible habit of running amok, placing files all over your
system, never to be found again! This way the mess is limited to one
directory (and sub-directories).

It also keeps the system clean. All the other binaries on your
system will be under the control of the package manager, whether that
be apt or rpm.

Usually 'make' will have option for a prefix (/usr/local) which makes
it easier. Reading the documentation will generally tell you. For some
small programs with a single binary, I sometimes just move it manually
to /usr/local/bin after compiling.

As for kernel packages: Most distributions allow you to compile your
own kernel packages with package manager tools and then integrate them
into the existing package manager. I can't say I've ever tried this,
but it would be advantageous to do it that way.

Andrew

_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug
Volker Kuhlmann
2011-01-27 08:41:51 UTC
Permalink
Post by Robin Paulson
this seems like a really dim question, but i can't begin to think of
how i might do it.
let's say i download a package in source form, and then use configure,
make, make install to install it. how do i uninstall it? it's not in
deb/rpm/whatever form, so i can't use apt/the red hat thingy to remove
it
The dim thing to do is not to ask how to tidy up, but to run make
install in the first place without thinking about the consequences ;)))

make install is mutually exclusive with good package management. The
latter was invented for a very good reason, and you just found out what
the reason is. Your only option is pretty much to delete files manually.
Good luck ;-)

/usr/local is left empty for your own make install mess except on some
disorganised distros, so the damage is at least limited to that place -
assuming you bothered to set the install prefix to /usr/local and made
sure you aren't dealing with a lousy Makefile. Don't run make install as
root (bad idea too to run make as root). Use setfacl to give another
user write access to /usr/local (remove when finished), and run make
install as that user - again that limits the damage to /usr/local.

Even better of course would be to knock up a package. It's not that
enormously difficult, esp if you start with something similar and
then substitute the content you want.

Volker
--
Volker Kuhlmann is list0570 with the domain in header.
http://volker.dnsalias.net/ Please do not CC list postings to me.

_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug
Rai Ricafrente
2011-01-27 09:34:40 UTC
Permalink
Post by Volker Kuhlmann
The dim thing to do is not to ask how to tidy up, but to run make
install in the first place without thinking about the consequences ;)))
make install is mutually exclusive with good package management. The
latter was invented for a very good reason, and you just found out what
the reason is. Your only option is pretty much to delete files manually.
Good luck ;-)
/usr/local is left empty for your own make install mess except on some
disorganised distros, so the damage is at least limited to that place -
assuming you bothered to set the install prefix to /usr/local and made
sure you aren't dealing with a lousy Makefile. Don't run make install as
root (bad idea too to run make as root). Use setfacl to give another
user write access to /usr/local (remove when finished), and run make
install as that user - again that limits the damage to /usr/local.
Even better of course would be to knock up a package. It's not that
enormously difficult, esp if you start with something similar and
then substitute the content you want.
Volker
I concur with Volker. It's pretty much 'manual' once you install from
source. Though there are some packages wherein make-uninstall is
available so it might be useful. That is if the directory where you
dropped the source files is still intact and untouched after you ran
make install.


Rai
Nevyn
2011-01-27 23:10:23 UTC
Permalink
Post by Volker Kuhlmann
The dim thing to do is not to ask how to tidy up, but to run make
install in the first place without thinking about the consequences ;)))
Colour me dim. On a personal system I don't tend to be all that
bothered. I want y application now and just want it to work. Thus I
wouldn't really be compiling myself. On a production machine or
something used for a lot of people though... turn up the brightness.
Post by Volker Kuhlmann
/usr/local is left empty for your own make install mess except on some
disorganised distros, so the damage is at least limited to that place -
assuming you bothered to set the install prefix to /usr/local and made
sure you aren't dealing with a lousy Makefile. Don't run make install as
root (bad idea too to run make as root). Use setfacl to give another
user write access to /usr/local (remove when finished), and run make
install as that user - again that limits the damage to /usr/local.
I've always used /usr/local/bin for things I've created. i.e. scripts
and the like. The reason for this is that if ever I need to migrate, I
know that I just have to back up:
/home
/etc
/usr/local/bin

And perhaps get a list of packages installed. This procedure has
changed just slightly with my work for schools. I tend to have a
script that I've applied to a vanilla install of whatever distribution
to come up with the image that I've created for the school(s).
Hopefully for the next distribution I only need to make a couple of
changes (although by a "couple" I mean some quite monumental changes
when using Ubuntu. Who thought unity was a good idea rather than the
netbook launcher?!?)

In which case, creating a deb and thus repository for those
"configure, make, make install" type applications is a bit of a
godsend. Truth be told, those scripts all end up there eventually too.

Regards,
Nevyn
http://nevsramblings.blogspot.com/

_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug
Phillip Hutchings
2011-01-27 23:19:44 UTC
Permalink
Post by Volker Kuhlmann
Post by Robin Paulson
this seems like a really dim question, but i can't begin to think of
how i might do it.
let's say i download a package in source form, and then use configure,
make, make install to install it. how do i uninstall it? it's not in
deb/rpm/whatever form, so i can't use apt/the red hat thingy to remove
it
The dim thing to do is not to ask how to tidy up, but to run make
install in the first place without thinking about the consequences ;)))
I always place things I compile myself in to /usr/local/<appname>/.
Adding to search paths is a bit of a pain, but nowhere near as much
pain as trying to extract the software from other location.
./configure --prefix=/usr/local/app normally works, though sometimes
it needs makefile hacking.
--
Phillip Hutchings
http://www.sitharus.com/

_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug
Bryan Baldwin
2011-01-28 22:41:18 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

It's not a dim question, because it is a question that has plagued computing since around the time computers were sophisticated enough to multitask. Maybe even before that. I'll have a bit of a chat about it, then tell you how I deal with the problem you're having (or jush SKIP AHEAD TO UNTIL YOU SEE "CHROOT INSTALL")

Installation/Uninstallation is a question of choosing your own battles. You can't avoid any fight at all, but you can limit the problems you'll face to just the ones that you can control.

If your distribution has the program you want in its repository, use it. It's the least troublesome way to get what you want almost completely hassle-free. If it isn't in any repository for your distribution, follow the distribution's guide for making a package for the packaging system, or switch to another distribution that supports the program you want.

CAVEAT about checkinstall: its only as good as its authors can make it. It works some of the time, but I've never been able to rely on it to do the Right Thing® in all circumstances. Its better to learn to make packages the way your distribution's maintainers do it.

If you have to have software that you build yourself, then you have some options. First, stop thinking of installation as a magical process that has some hidden secret sauce that turns everything on. Installing a program is simply copying a collection of related files to the right places on a computer with the right file privileges. Even on Windows, programs do not necessarily have to dick around making registry entries and blah blah blah(vomit). Otherwise, notepad++, vlc, emacs, etc wouldn't just work when run off a flash drive. But enough ranting.

BUILDING THE KERNEL:

All you really need to install the kernel is the linux binary, the initrd file, and the system map IIRC, and modules (if you built any). It really isn't any harder to do then any other software unless you intend to do a custom configuration. In the simplest form, if you build your system drivers into the kernel you can configure, make, and just copy your linux binary to /boot then update grub and reboot. For a good guide on kernel building, see Linux from Scratch or DIY Linux.

USING "make uninstall":

Developers using the GNU build tools make Makefiles that help the program "make" to do the right things when building binaries from source code. Even some interpreted programs that do not require compilation use "make" to direct their installation. If the program you want to install has an "uninstall" rule, you can use it to uninstall after doing a "make install" with approximently the same confidence as you have in the sanity of the developer. If you aren't sure that the program comes with "make uninstall" and are frightened to install without one, then you could "./configure" the package and then try:

$ grep "uninstall" Makefile

It isn't foolproof, but its worth a look to see if grep finds anything. If not, don't rely on there being an uninstall rule. Sometimes there is an uninstall which won't be apparent in any other way until after you've gone out on a limb and did the install. Anyway, if you know there is an uninstall rule, you can use it. If you want something that gives you a little more control, and you don't mind a little more work, then try:

CHROOT INSTALL

The funny thing is that we are not actually going to invoke "chroot". There are ways we aren't going to cover and don't need to worry about to do builds inside an actual chroot. But for now, in this guide, all chroot means is that we are going to trick "make" into thinking your root "/" is elsewhere, thus controlling where the files get deposited. You do this by setting the environment variable DESTDIR to the name of another directory into which you wish your compiled files to go.

CAVEAT: Not all packages that use GNU make will use or respect the DESTDIR variable (eg. glibc). In some cases you will need to do a little investigating to be sure what environment variable your package's Makedfile respects. In extreme cases, you may need to hand edit a Makefile to force this behavior. But 99.9% of the time DESTDIR works. Non GNU build systems probably do everything differently, so don't assume anything here will work with those. Check google for Linux from Scratch or DIY Linux. They might have pointers for build systems other then GNU's.

Its very easy. Configure and build in the usual way from the top level of your source code directory:

# configure and make the package
# you could run this exactly as typed (if you have no custom flags you want to pass to "make")
$ ./configure; make

When its finished building, as your normal unpriviledged user:

# install everything in an alternative location
# CAVEAT; do not run this as written here. read on to
# learn which bits to change before issuing the command
$ make DESTDIR=/home/$USER/<my good directory>/package-name$( date +%Y%m%d ) install

where you will replace <my good directory> with path name that exists and is writable, AND package-name with a real name for the software you are building. The "package-name$( date +%Y%m%d)" in that command will get "make" to make a directory with a name and a date stamp. GNU make will slurp up all the stuff that "make install" wants and then drop it into the <my good directory>/package-name$( date +%Y%m%d ) directory. Throughout this guide, I will refer to these locations as written in the example command, although they will have different unique names on your system. Inside the "package-name$( date +%Y%m%d)" directory are all the files for your program, arranged neatly in the order they are meant to exist from root "/". You can install the package by "cd" to <my good directory>/package-name$( date +%F), and then

# install from uncompressed chroot directory
# you can run this exactly as typed
$ tar cf - * | ( cd /; sudo tar xf - )

which will copy everything under your chroot directory to your real root. Most of the time this is perfectly safe. At least as safe as the sanity of the developer. Later you can uninstall the package by "cd" to <my good directory>/package-name$( date +%Y%m%d ) and doing:

# uninstall from uncompressed chroot directory
# you can run this exactly as typed
$ find * -type f | while read i; do sudo rm -v /"${i}"; done

CAVEAT: mistyping this command can destroy your entire system!!! NEVER EVER "rm -R" HERE. NOT EVER!

Of course, keeping the entire build in two places is a waste of disk. I usually make tarballs. To do it just "cd" into <my good directory>/package-name$( date +%Y%m%d ) and:

# compress chroot directory into an xz'd tarball\
# change "package-name$( date +%Y%m%d ).tar.xz" to the real
# name of your tarball before issuing the command
$ tar cf - * | xz -c9 >../package-name$( date +%Y%m%d ).tar.xz

CAVEAT: Its important to remember to tar from _inside_ the "package-name$( date +%Y%m%d )" directory. Otherwise, if you tarred it up with "package-name$( date +%Y%m%d )" as the tarball root, it wouldn't work the way you'd expect if you tried to install or uninstall from it.

Now you should have the file "package-name$( date +%Y%m%d ).tar.xz" in your <my good directory>. You can use this file to install/uninstall the software so you can delete the package-name$( date +%Y%m%d ) directory. To install from tarball, "cd" to your root "/" path and

# install package from tarball
# change <my good directory> to the real path name you installed into
# change "package-name$( date +%Y%m%d ).tar.xz" to the real tarball file name
$ sudo tar xf /home/$USER/<my good directory>/package-name$( date +%Y%m%d ).tar.xz

# uninstall package from tarball
# change <my good directory> to the real path name you installed into
# change "package-name$( date +%Y%m%d ).tar.xz" to the real tarball file name
$ sudo tar tf /home/$USER/<my good directory>/package-name$( date +%Y%m%d ).tar.xz | while read i; do rm -v /"${i}"; done

CAVEAT: mistyping this command can destroy your entire system!!! NEVER EVER "rm -R" HERE. NOT EVER!

Take this for all in all, it was but a guide. Hopefully, we will never see its like again ;)

Regards,

Bryan
Post by Robin Paulson
this seems like a really dim question, but i can't begin to think of
how i might do it.
let's say i download a package in source form, and then use configure,
make, make install to install it. how do i uninstall it? it's not in
deb/rpm/whatever form, so i can't use apt/the red hat thingy to remove
it
deleting the files seems clumsy and ignores undoing any scripted steps
carried out during the install
what if i installed a kernel - is it as simple as editing the grub cfg files?
cheers
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNQ0YNAAoJEHblvm1J+WqMtjcH/RwrhlPgOpOQ3u8IjjzyatI5
pHrF+yDA3l92S4SZzX4EqoH9YmjC+J8gZ4u93qA4F7SoZ6IAxeIqVrano1yrtt7B
UXd/pAv9IbmH6KWLvjPM5SEGLyRrEH8P6ep1ZN/hDDLOlT/KDDLEWhNiXqTmWHsP
7F/dBtHoxUSpMUy88bLaxp9OE09lK6DPh4V2kfwYr7vDt2Z05mCjb/t1w3VA/+7p
2ZavUv9aP90XaAj7CRod5fstxJahGXrnvTjzPQD7iFQm0VCwiZXvKid8w4AtevFi
K9qwmFaRuwiwOvc/puFdB+yBT4CRwrNiiLuOi1YmaOL0mI7K6tDCwDr+qkoCURw=
=7Arq
-----END PGP SIGNATURE-----

_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug
Nevyn
2011-01-28 23:10:07 UTC
Permalink
Post by Bryan Baldwin
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
It's not a dim question, because it is a question that has plagued computing since around the time computers were sophisticated enough to multitask. Maybe even before that. I'll have a bit of a chat about it, then tell you how I deal with the problem you're having (or jush SKIP AHEAD TO UNTIL YOU SEE "CHROOT INSTALL")
Installation/Uninstallation is a question of choosing your own battles. You can't avoid any fight at all, but you can limit the problems you'll face to just the ones that you can control.
If your distribution has the program you want in its repository, use it. It's the least troublesome way to get what you want almost completely hassle-free. If it isn't in any repository for your distribution, follow the distribution's guide for making a package for the packaging system, or switch to another distribution that supports the program you want.
CAVEAT about checkinstall: its only as good as its authors can make it. It works some of the time, but I've never been able to rely on it to do the Right Thing® in all circumstances. Its better to learn to make packages the way your distribution's maintainers do it.
If you have to have software that you build yourself, then you have some options. First, stop thinking of installation as a magical process that has some hidden secret sauce that turns everything on. Installing a program is simply copying a collection of related files to the right places on a computer with the right file privileges. Even on Windows, programs do not necessarily have to dick around making registry entries and blah blah blah(vomit). Otherwise, notepad++, vlc, emacs, etc wouldn't just work when run off a flash drive. But enough ranting.
All you really need to install the kernel is the linux binary, the initrd file, and the system map IIRC, and modules (if you built any). It really isn't any harder to do then any other software unless you intend to do a custom configuration. In the simplest form, if you build your system drivers into the kernel you can configure, make, and just copy your linux binary to /boot then update grub and reboot. For a good guide on kernel building, see Linux from Scratch or DIY Linux.
$ grep "uninstall" Makefile
CHROOT INSTALL
The funny thing is that we are not actually going to invoke "chroot". There are ways we aren't going to cover and don't need to worry about to do builds inside an actual chroot. But for now, in this guide, all chroot means is that we are going to trick "make" into thinking your root "/" is elsewhere, thus controlling where the files get deposited. You do this by setting the environment variable DESTDIR to the name of another directory into which you wish your compiled files to go.
CAVEAT: Not all packages that use GNU make will use or respect the DESTDIR variable (eg. glibc). In some cases you will need to do a little investigating to be sure what environment variable your package's Makedfile respects. In extreme cases, you may need to hand edit a Makefile to force this behavior. But 99.9% of the time DESTDIR works. Non GNU build systems probably do everything differently, so don't assume anything here will work with those. Check google for Linux from Scratch or DIY Linux. They might have pointers for build systems other then GNU's.
# configure and make the package
# you could run this exactly as typed (if you have no custom flags you want to pass to "make")
$ ./configure; make
# install everything in an alternative location
# CAVEAT; do not run this as written here. read on to
#         learn which bits to change before issuing the command
$ make DESTDIR=/home/$USER/<my good directory>/package-name$( date +%Y%m%d ) install
where you will replace <my good directory> with path name that exists and is writable, AND package-name with a real name for the software you are building. The "package-name$( date +%Y%m%d)" in that command will get "make" to make a directory with a name and a date stamp. GNU make will slurp up all the stuff that "make install" wants and then drop it into the <my good directory>/package-name$( date +%Y%m%d ) directory. Throughout this guide, I will refer to these locations as written in the example command, although they will have different unique names on your system. Inside the "package-name$( date +%Y%m%d)" directory are all the files for your program, arranged neatly in the order they are meant to exist from root "/". You can install the package by "cd" to <my good directory>/package-name$( date +%F), and then
# install from uncompressed chroot directory
# you can run this exactly as typed
$ tar cf - * | ( cd /; sudo tar xf - )
# uninstall from uncompressed chroot directory
# you can run this exactly as typed
$ find * -type f | while read i; do sudo rm -v /"${i}"; done
CAVEAT: mistyping this command can destroy your entire system!!! NEVER EVER "rm -R" HERE. NOT EVER!
# compress chroot directory into an xz'd tarball\
# change "package-name$( date +%Y%m%d ).tar.xz" to the real
# name of your tarball before issuing the command
$ tar cf - * | xz -c9 >../package-name$( date +%Y%m%d ).tar.xz
CAVEAT: Its important to remember to tar from _inside_ the "package-name$( date +%Y%m%d )" directory. Otherwise, if you tarred it up with "package-name$( date +%Y%m%d )" as the tarball root, it wouldn't work the way you'd expect if you tried to install or uninstall from it.
Now you should have the file "package-name$( date +%Y%m%d ).tar.xz" in your <my good directory>. You can use this file to install/uninstall the software so you can delete the package-name$( date +%Y%m%d ) directory. To install from tarball, "cd" to your root "/" path and
# install package from tarball
# change <my good directory> to the real path name you installed into
# change "package-name$( date +%Y%m%d ).tar.xz" to the real tarball file name
$ sudo tar xf /home/$USER/<my good directory>/package-name$( date +%Y%m%d ).tar.xz
# uninstall package from tarball
# change <my good directory> to the real path name you installed into
# change "package-name$( date +%Y%m%d ).tar.xz" to the real tarball file name
$ sudo tar tf /home/$USER/<my good directory>/package-name$( date +%Y%m%d ).tar.xz | while read i; do rm -v /"${i}"; done
CAVEAT: mistyping this command can destroy your entire system!!! NEVER EVER "rm -R" HERE. NOT EVER!
Take this for all in all, it was but a guide. Hopefully, we will never see its like again ;)
Regards,
       Bryan
Quick question. I used to work with a software packaging team when I
worked with EDS. The way to do it was to load up a program which would
monitor files and the Windows registry. Assuming you had a VM which
you could turn off as many services as possible, is there a way to
monitor what files are changed en masse? Assuming that the install
file might not necessarily use the "configure ; make ; make install"
pattern so you don't necessarily have a script you could follow...

Is the easiest way to do a ls -lR /* before and after an install and
do a diff between the two resulting files looking for new files and
changed timestamps?

Regards,
Nevyn
http://nevsramblings.blogspot.com/

_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug
Bryan Baldwin
2011-01-29 05:50:27 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Nevyn
Quick question. I used to work with a software packaging team when I
worked with EDS. The way to do it was to load up a program which would
monitor files and the Windows registry. Assuming you had a VM which
you could turn off as many services as possible, is there a way to
monitor what files are changed en masse? Assuming that the install
file might not necessarily use the "configure ; make ; make install"
pattern so you don't necessarily have a script you could follow...
Is the easiest way to do a ls -lR /* before and after an install and
do a diff between the two resulting files looking for new files and
changed timestamps?
I remember reading about a library extension that could be used to track
file changes. It seemed really clumsy to me so I never used it. If you
can't DESTDIR your install, building in a real chroot and diffing the
filesystem is the way I would go.

Regard,

Bryan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNQ6qjAAoJEHblvm1J+WqM4lQH/2dRFP4GDhiZ+3T153NQu35s
h248rz/QqFvs6CDPsfBpBoW0IOuinvEDi/2EIocr/Tvfl3udYwoy9vhwh/iRuRJV
r8ybI1VrEt17baL615xf5mAGJh8DHdl1ewVWaeOMf9qta3OVY5G2N+zKXOuI0z1c
geJbHjXFtGAlLeiJ0mxxCVsNB9iWh3lbK+vBuHQ2bu6xr5Thn0TV8Ti0UkPF4mmd
FmeHo7Z2OLqo95Kzdab4+RKOqoBOHtwSaOtw2++jlBwfLYpsJXxiMcECU1vpev2S
DmyUqy4MA0yEkXWAbVFs//Vb5K6/8JviZvA8A13kC9eFqRe+ySViwf2cXLSJuGk=
=mIIu
-----END PGP SIGNATURE-----

_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug
Daniel Pittman
2011-01-29 20:11:07 UTC
Permalink
Post by Nevyn
Post by Bryan Baldwin
It's not a dim question, because it is a question that has plagued computing since around the time computers were sophisticated enough to multitask. Maybe even before that. I'll have a bit of a chat about it, then tell you how I deal with the problem you're having (or jush SKIP AHEAD TO UNTIL YOU SEE "CHROOT INSTALL")
[...]
Post by Nevyn
Quick question. I used to work with a software packaging team when I
worked with EDS. The way to do it was to load up a program which would
monitor files and the Windows registry. Assuming you had a VM which
you could turn off as many services as possible, is there a way to
monitor what files are changed en masse? Assuming that the install
file might not necessarily use the "configure ; make ; make install"
pattern so you don't necessarily have a script you could follow...
That is, in fact, how the checkinstall program actually works. :)

In practice the "packages" it builds are like what things like Ghost
used to do for "packages" on Win32: the bundle of changes seen from
one point in time to another, wrapped up.

Regards,
Daniel
--
⎋ Puppet Labs Developer – http://puppetlabs.com
✉ Daniel Pittman <***@rimspace.net>
✆ Contact me via gtalk, email, or phone: +1 (503) 893-2285
♲ Made with 100 percent post-consumer electrons

_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug
Volker Kuhlmann
2011-01-29 02:23:27 UTC
Permalink
On Sat 29 Jan 2011 11:41:18 NZDT +1300, Bryan Baldwin wrote:

[Long recipe for compiling source somewhat safely.]

Your method still has a few problems. GNU source is usually well-behaved
can can be handled easily. make DESTDIR= requires good support from the
Makefile, but if the Makefile was that good, you wouldn't have the
trouble in the first place which you're trying to solve with DESTDIR=.
Same goes for make checkinstall - if you need it it's not there, if it's
there you can't rely on it (or don't need it).

I can really only see approximately these options:

1) Run make install. You knew what you're doing. The tidy-up goes with
mkfs. If you're happy with SNAFU, you don't have a problem.

2) Run make and make install as some throw-away user and install to
/tmp/blabla, then look what it's installing. make clean; make for the
final destination (strongly suggest /usr/local), but DON'T run make
install. Copy the needed files manually and make+keep a list of them. If
the app/Makefile doesn't support it, choose one of the other options. If
there's only one bin and one man file, fine, easy.

3) I use a script called build. It sets up a chroot environment for me
automatically, with clean distro packages, and calls the package
builder. One could drop the package building part and manually collect
what's created by make install in the chroot. This method is the only
semi-safe way for apps that need to be compiled or installed as root.

The successor to this is called osc I think (haven't used it yet) and
there is an online version, the principle is the same.

4) Learn how to make packages for your distro. It's not that hard,
though it can be somewhat time-consuming for PITA apps. This option is
the only future-proof one and becomes rapidly more appealing when you
need to install on more than 1 computer, and with any minute more you
waste on the first 2 options.

Volker
--
Volker Kuhlmann is list0570 with the domain in header.
http://volker.dnsalias.net/ Please do not CC list postings to me.

_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug
Cliff Pratt
2011-01-30 20:17:57 UTC
Permalink
Post by Robin Paulson
this seems like a really dim question, but i can't begin to think of
how i might do it.
let's say i download a package in source form, and then use
configure, make, make install to install it. how do i uninstall it?
it's not in deb/rpm/whatever form, so i can't use apt/the red hat
thingy to remove it
deleting the files seems clumsy and ignores undoing any scripted
steps carried out during the install
what if i installed a kernel - is it as simple as editing the grub cfg files?
You could run 'make install' with -n or some bedug flags to see what it did.

Cheers,

Cliff

_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug

Continue reading on narkive:
Loading...