How to completely remove self-compiled programs?

cyker · 2010-03-02 13:41:41

As we all know, software installed by pacman can be easily removed by

pacman -R softwarename

But if we download the source code from web, and install it by ourselves using

./configure
make
make install

Then if we want to delete it, how can we make sure that this is done completely? I mean, no junk files are left.

PS. Suppose we have deleted the source folder and cannot use

make uninstall

wonder · 2010-03-02 13:46:09

run again ./configure with the same options and then make uninstall ?

Last edited by wonder (2010-03-02 13:46:24)

davidgurvich · 2010-03-02 16:15:02

Place all programs you build in a separate path from those installed with pacman. A popular place is /opt and /usr/local. Only a few packages use /opt and none use /usr/local that I know of. On certain systems I use /usr/local/apps/APP_NAME as the prefix or /opt/APP_NAME.

eldragon · 2010-03-02 16:45:12

i would definately learn how to use makepkg in the future...

that way, you can remove your installed apps with pacman

cyker · 2010-03-02 17:03:46

davidgurvich wrote:

Place all programs you build in a separate path from those installed with pacman. A popular place is /opt and /usr/local. Only a few packages use /opt and none use /usr/local that I know of. On certain systems I use /usr/local/apps/APP_NAME as the prefix or /opt/APP_NAME.

If I can do that, that's fine. But most of the time it's a bit annoying making the change of the destination folder. If the code writer doesn't give you the chance of change, and you don't want to look through the code, things are still a mass.

lolilolicon · 2010-03-02 17:03:47

There's an "easy" way if there's no 'make uninstall':

1. Write a PKGBUILD within which you write exactly how you installed the program inside the build() function.
2. makepkg
3. pacman -Uf <pkg.tar.gz>
4. pacman -R <pkgname>

cyker · 2010-03-02 17:07:26

eldragon wrote:

i would definately learn how to use makepkg in the future...
that way, you can remove your installed apps with pacman

Yeah, makepkg is a good idea! If you don't know how to use that, there is a tutorial on my blog you may refer to at http://blog.cykerway.com/?p=215

cyker · 2010-03-02 17:15:10

lolilolicon wrote:

There's an "easy" way if there's no 'make uninstall':
1. Write a PKGBUILD within which you write exactly how you installed the program inside the build() function.
2. makepkg
3. pacman -Uf <pkg.tar.gz>
4. pacman -R <pkgname>

Yes, we can put ./configure and make inside the build() function

But if put make install in it and run

makepkg

Will the files be copied to the real path(such as /usr/local/) or the relative path based on / but actually encapsulated in the .tar.gz package when this line is executed in build()? Is any mechanism in makepkg that make it actually do the latter?

flamelab · 2010-03-02 17:18:55

add "make DESTDIR=/the/path/you/want install"

eldragon · 2010-03-02 17:23:16

cyker wrote:

Will the files be copied to the real path(such as /usr/local/) or the relative path based on / but actually encapsulated in the .tar.gz package when this line is executed in build()? Is any mechanism in makepkg that make it actually do the latter?

no, makepkg sets everything up so that files get "installed" into the pkg.tar.gz file.

then pacman copies those files during installation where they belong.

pacman -R removes them

tomk · 2010-03-02 17:26:42

cyker wrote:

Is any mechanism in makepkg that make it actually do the latter?

cyker - don't ask questions like that here, when it's all covered in fine detail in the wiki. The Arch Build System is at the very heart of Arch, and it is well documented and very easy to use.

cyker · 2010-03-02 17:28:44

eldragon wrote:

cyker wrote:
Will the files be copied to the real path(such as /usr/local/) or the relative path based on / but actually encapsulated in the .tar.gz package when this line is executed in build()? Is any mechanism in makepkg that make it actually do the latter?
no, makepkg sets everything up so that files get "installed" into the pkg.tar.gz file.
then pacman copies those files during installation where they belong.
pacman -R removes them

I mean, when you are running make install in the build() function, additional files may be generated.
If you don't run make install and stop after running make, then the compiled binary files won't be automatically collected in the pkg folder. Maybe DESTDIR is a good choice.

Runiq · 2010-03-02 17:29:01

flamelab wrote:

add "make DESTDIR=/the/path/you/want install"

+1, that's what the DESTDIR variable and /usr/local are for actually. See here.

cyker · 2010-03-02 17:38:53

tomk wrote:

cyker wrote:
Is any mechanism in makepkg that make it actually do the latter?
cyker - don't ask questions like that here, when it's all covered in fine detail in the wiki. The Arch Build System is at the very heart of Arch, and it is well documented and very easy to use.

Dear tomk, I think you may not carefully read my question. I know the mechanism of makepkg-pacman-AUR-ABS well and I even wrote a tutorial. I have read the ArchWiki thoroughly and didn't find the information I need. Actually I have done a little experiment just now and things turn out to be that makepkg doesn't have that mechanism if run normally - It cannot prevent scripts run in the build() function to generate files outside the building folder so it may not solve the problem I submitted before. And I'm still looking for a solution to the problem I proposed.

lolilolicon · 2010-03-02 18:50:33

cyker, you need to understand better the Arch Build System. And please read some examples from abs/aur, and actually do some packaging yourself.

I thought about mentioning DESTDIR="$pkgdir" after my last post but didn't bother... As flamelab has already mentioned, you can control the packaging just as precise as you want.

To give you a basic idea of it, here's an example:

... ... ...
build() {
  cd "$srcdir/$pkgname-$pkgver"
  ./configure --prefix=/usr
  make
  make DESTDIR="$pkgdir/" install
  # install extra stuff not covered by `make install`
  install -D -m 644 LICENSE "$pkgdir"/usr/share/licenses/$pkgname/LICENSE
}

After `makepkg`, do a `tree pkg` to see the final installation structure. What the pkg.tar.gz contains is just this "$pkgdir" (pkg) plus some meta info like ".PKGINFO" etc.

cyker wrote:

It cannot prevent scripts run in the build() function to generate files outside the building folder

Why would it? Makepkg gives you all freedom including `rm -rf /` in your build() function and doesn't give a shit about it. It's all up to you.
But normally, makepkg shouldn't generate anything out of the "building folder" ($startdir, ie where you run `makepkg`), while what's installed by pacman is always everything under $pkgdir

To sum it all up, I'll quote tomk

tomk wrote:

cyker - don't ask questions like that here, when it's all covered in fine detail in the wiki. The Arch Build System is at the very heart of Arch, and it is well documented and very easy to use.

And read the second sentence of this post as a second hint

Edit: typo

Last edited by lolilolicon (2010-03-02 19:00:53)

tomk · 2010-03-02 18:57:22

cyker - I read your question. You wanted to know what would happen if you put 'make install' in your build function. This indicates to me that you have little or no experience using makepkg to build Arch packages, because if you had, you would know what would happen if you did that. Every single piece of relevant documentation includes the recommendation repeated by flamelab earlier in this thread. I haven't read your tutorial, but I sincerely hope that you have included it too. I have my doubts though:

cyker wrote:

Maybe DESTDIR is a good choice.

To summarise - you are looking for a solution to a problem that does not exist when a PKGBUILD is written correctly.

cyker · 2010-03-02 20:24:59

tomk wrote:

cyker - I read your question. You wanted to know what would happen if you put 'make install' in your build function. This indicates to me that you have little or no experience using makepkg to build Arch packages, because if you had, you would know what would happen if you did that. Every single piece of relevant documentation includes the recommendation repeated by flamelab earlier in this thread. I haven't read your tutorial, but I sincerely hope that you have included it too. I have my doubts though:
cyker wrote:
Maybe DESTDIR is a good choice.
To summarise - you are looking for a solution to a problem that does not exist when a PKGBUILD is written correctly.

If everyone acts according to a give specification, that's fine. I won't post here. But sometimes you'll find badly-written install scripts that make compiled files scatter everywhere in your system. Of course you may make your system clean again by running make uninstall -- if
1. The author of the code successfully manage the details
2. You still have the source code(at least the makefile)

So initially my question has nothing to do with makepkg. I just wonder how to make the system clean if the source code, including the makefile, is lost. This makepkg tool is just proposed as a potential solution to my problem. But I tested it and found no mechanism is provided by makepkg to prevent make install writing files outside the building folder you want. So a badly-written makefile could still make your system a mess -- makepkg won't save that!

Even if PKGBUILD is written correctly, it is of no use. If the makefile want to write something elsewhere during installation, it still can do that.

I appreciate all of your answers. But my problem is based on a bad source code(perhaps makefile, but not PKGBUILD). Suppose, during make install, it will write junk files to /usr, /bin, /lib, etc. You don't want that happen, right? But you may not carefully read each line of the makefile of each software you install. I want a mechanism to make the whole compilation not generate files(final binaries and intermediate files and temporary files and config files) outside the building folder so that situation can be controlled. Or it will record each file generated in any methods so that when you want to delete them, you can delete them completely.

Last edited by cyker (2010-03-02 20:49:14)

ataraxia · 2010-03-02 20:56:16

cyker wrote:

Even if PKGBUILD is written correctly, it is of no use. If the makefile want to write something elsewhere during installation, it still can do that.
I appreciate all of your answers. But my problem is based on a bad source code(perhaps makefile, but not PKGBUILD). Suppose, during make install, it will write junk files to /usr, /bin, /lib, etc. You don't want that happen, right? But you may not carefully read each line of the makefile of each software you install. I want a mechanism to make the whole compilation not generate files(final binaries and intermediate files and temporary files and config files) outside the building folder so that situation can be controlled. Or it will record each file generated in any methods so that when you want to delete them, you can delete them completely.

You don't run makepkg as root, so it can't make that kind of a mess when makepkg runs "make install" for you.

cyker · 2010-03-02 21:08:10

ataraxia wrote:

cyker wrote:
Even if PKGBUILD is written correctly, it is of no use. If the makefile want to write something elsewhere during installation, it still can do that.
I appreciate all of your answers. But my problem is based on a bad source code(perhaps makefile, but not PKGBUILD). Suppose, during make install, it will write junk files to /usr, /bin, /lib, etc. You don't want that happen, right? But you may not carefully read each line of the makefile of each software you install. I want a mechanism to make the whole compilation not generate files(final binaries and intermediate files and temporary files and config files) outside the building folder so that situation can be controlled. Or it will record each file generated in any methods so that when you want to delete them, you can delete them completely.
You don't run makepkg as root, so it can't make that kind of a mess when makepkg runs "make install" for you.

All right, I'll pose a simple example.

In makefile,

...
install:
  touch ~/junkfile1
  touch ~/junkfile2
  touch ~/junkfile3
...

Run make install, no matter inside makepkg's build() or standalone, your home directory will be a mess.
It's a bit exaggerated. Proficient programmers won't write code like this. But I have encountered such problems when running codes by students. They ruined my file system structure by making a lot of unnecessary tmp files. I don't want that happen again.

lolilolicon · 2010-03-03 01:03:35

Edit: nvm; as a side note: A re-installation a day, makes perfect security.

Moderator edit: I'm sure there are more appropriate ways than insults to channel your frustration about this topic

Last edited by .:B:. (2010-03-03 17:24:35)

ngoonee · 2010-03-03 03:36:52

For programs which behave that way, report a bug to the author. You can also use the PKGBUILD to 'clean up' after those programs. In your example, add rm ~/junkfile1 etc to the PKGBUILD.

If 'make install' doesn't play nice with DESTDIR the author really needs to get his/her act together.

cyker · 2010-03-03 06:15:39

ngoonee wrote:

For programs which behave that way, report a bug to the author. You can also use the PKGBUILD to 'clean up' after those programs. In your example, add rm ~/junkfile1 etc to the PKGBUILD.
If 'make install' doesn't play nice with DESTDIR the author really needs to get his/her act together.

In this way you mean it's the code writer's duty to make his code functions according to the convention? But is there any mechanism to prevent those who don't follow these coding rules from ruining your computer? For example, to record junkfile1,junkfile2,junkfile3... in the example above. I like the pacman way of installing software since it maintains a list of each file you've installed and you can see it clearly. I just wonder whether there is a general solution like this for those self-compiled codes.

All the solutions above are based on a reasonable programmer. But sometimes you may have to install codes written by newbies. They may not intend to do harm to your computer, but their code may generate files in uncertain path and forget to clean it completely(ex. imperfect make uninstall or so). You'll find it neither easy nor happy to clean these files up. I'm wondering whether chroot could be a solution.

cyker · 2010-03-03 06:31:39

lolilolicon wrote:

Don't quote that crap, a topic report is plenty

So why hiding the text using the color? People went here to ask questions and look for solutions where they cannot get from wiki and doc. If you can answer, that's good. If you cannot, don't be so rude. Otherwise, shame on you. If you'd like to re-install your system once per day, I don't care. I just want to make it clear which files are generated when running an installation script such as make install.

Last edited by .:B:. (2010-03-03 17:26:13)

ngoonee · 2010-03-03 07:13:19

cyker wrote:

ngoonee wrote:
For programs which behave that way, report a bug to the author. You can also use the PKGBUILD to 'clean up' after those programs. In your example, add rm ~/junkfile1 etc to the PKGBUILD.
If 'make install' doesn't play nice with DESTDIR the author really needs to get his/her act together.
In this way you mean it's the code writer's duty to make his code functions according to the convention? But is there any mechanism to prevent those who don't follow these coding rules from ruining your computer? For example, to record junkfile1,junkfile2,junkfile3... in the example above. I like the pacman way of installing software since it maintains a list of each file you've installed and you can see it clearly. I just wonder whether there is a general solution like this for those self-compiled codes.
All the solutions above are based on a reasonable programmer. But sometimes you may have to install codes written by newbies. They may not intend to do harm to your computer, but their code may generate files in uncertain path and forget to clean it completely(ex. imperfect make uninstall or so). You'll find it neither easy nor happy to clean these files up. I'm wondering whether chroot could be a solution.

A 'general' solution would require keeping track of what every install file is doing. Not very scalable. As you mention, though, chroots are a good solution, that's how our packages/devs are supposed to build packages (mainly to prevent dependency problems, but works for this as well).

You could just have a 'throw-away' chroot for building, install the built package on your own system, and delete the chroot every once in a while. Or do a diff before and after building a package and tell the programmer he's generating nonsense files. Or make sure your chroot has non-writable ~, which is the only possible problem (everything else can't be written to because makepkg uses fakeroot permissions).

Just to be clear, pacman does NOT use make uninstall. Uninstallation is a simple matter of deleting the files listed as belonging to a package.

hullap · 2010-03-03 07:28:10

for the future, you could use Wocka which is like checkinstall for arch

Arch Linux

#1 2010-03-02 13:41:41

How to completely remove self-compiled programs?

#2 2010-03-02 13:46:09

Re: How to completely remove self-compiled programs?

#3 2010-03-02 16:15:02

Re: How to completely remove self-compiled programs?

#4 2010-03-02 16:45:12

Re: How to completely remove self-compiled programs?

#5 2010-03-02 17:03:46

Re: How to completely remove self-compiled programs?

#6 2010-03-02 17:03:47

Re: How to completely remove self-compiled programs?

#7 2010-03-02 17:07:26

Re: How to completely remove self-compiled programs?

#8 2010-03-02 17:15:10

Re: How to completely remove self-compiled programs?

#9 2010-03-02 17:18:55

Re: How to completely remove self-compiled programs?

#10 2010-03-02 17:23:16

Re: How to completely remove self-compiled programs?

#11 2010-03-02 17:26:42

Re: How to completely remove self-compiled programs?

#12 2010-03-02 17:28:44

Re: How to completely remove self-compiled programs?

#13 2010-03-02 17:29:01

Re: How to completely remove self-compiled programs?

#14 2010-03-02 17:38:53

Re: How to completely remove self-compiled programs?

#15 2010-03-02 18:50:33

Re: How to completely remove self-compiled programs?

#16 2010-03-02 18:57:22

Re: How to completely remove self-compiled programs?

#17 2010-03-02 20:24:59

Re: How to completely remove self-compiled programs?

#18 2010-03-02 20:56:16

Re: How to completely remove self-compiled programs?

#19 2010-03-02 21:08:10

Re: How to completely remove self-compiled programs?

#20 2010-03-03 01:03:35

Re: How to completely remove self-compiled programs?

#21 2010-03-03 03:36:52

Re: How to completely remove self-compiled programs?

#22 2010-03-03 06:15:39

Re: How to completely remove self-compiled programs?

#23 2010-03-03 06:31:39

Re: How to completely remove self-compiled programs?

#24 2010-03-03 07:13:19

Re: How to completely remove self-compiled programs?

#25 2010-03-03 07:28:10

Re: How to completely remove self-compiled programs?

Board footer