[Solved] General linux best-practices with makefile

frank604 · 2016-10-15 04:06:57

I was in the #archlinux irc a few weeks ago and recommended to compile dwm via the provided makefile, and using

sudo make clean install

The makefile points to /usr/local/bin/dwm so sudo is required.

This was frowned upon by quite a few people and I admit, I am quite new to compiling and directory placement for the program. I've asked for a reason but this request fell on deaf ears. I am curious and always look to further my knowledge with linux. Googling 'best practices makefile' only results in the technicalities of library modules, tips on wildcards, etc.

My assumption is to avoid installing into root and instead point installation directory to a user owned directory such as ~/bin but nothing really solid is coming through in my search.

Links or your opinion on 'best practices for makefile' are very welcome.

edit: truncated title to fit solved tag

Last edited by frank604 (2016-10-15 07:30:15)

oliver · 2016-10-15 04:31:04

Could the folks in the Arch IRC be recommending you don't go outside pacman (or ABS/AUR) rather than balking at your specific binary location?

jasonwryan · 2016-10-15 04:38:08

For a tiny, discrete binary like dwm, I have no problem with

make && sudo make install

basica · 2016-10-15 05:28:03

I'm not really understanding what you're getting at. If you simply want to install it elsewhere then just modify the prefix to something you prefer. So if it's by default /usr/local and you decided you want it in ~/dwm (or whatever) just modify it accordingly. Then you can do a make install without root access, and without it installing it in a global directory.

The only thing I can think of that people would take issue with, is that it's default install location is /usr/local/ instead of /usr/ which is what a lot of distros (including Arch) prefer for their package install locations. Having it installed under / doesn't really seem like it's a problem really..

In terms of best practices, file locations *should* adhere to the FHS, but in reality there are no hard and fast rules.

EDIT: I downloaded the source code to have a quick look. Typically you can run a ./configure --help to get a list of configure options that you run before you run a make && make install. For this package, it looks like you need to modify the config.mk file manually prior to running make && make install.

Last edited by basica (2016-10-15 05:30:23)

Scimmia · 2016-10-15 05:35:39

basica wrote:

The only thing I can think of that people would take issue with, is that it's default install location is /usr/local/ instead of /usr/ which is what a lot of distros (including Arch) prefer for their package install locations. Having it installed under / doesn't really seem like it's a problem really.

People will take issue with putting untracked files in /usr. Not to mention that unless you know *exactly* what the makefile is doing, running make install as root is a craps shoot, you could end up with things all over the place to cause problems.

basica · 2016-10-15 05:42:38

Scimmia wrote:

People will take issue with putting untracked files in /usr. Not to mention that unless you know *exactly* what the makefile is doing, running make install as root is a craps shoot, you could end up with things all over the place to cause problems.

Ah yes, I see now. Well, this is why it's probably a good idea to create your own PKGBUILD (if it's not in the repos or AUR already). Though I suppose if you're really against packaging it (not sure why, seems to add a lot of inconvenience not doing so), you could always do a make DESTIDIR=/whatever install so you can see what's going on.

frank604 · 2016-10-15 07:29:21

@oliver, If you mean not being tracked by pacman, I feel that is the most likely reason now after reading scimmia's response. You are right in that this wasn't about location after all.

@jasonwryan, me too.

@basica, I know the install location can be changed. That wasn't the point of my post. The point was to figure out what is good practice/bad practice when dealing with install locations via makefile. Why was it discouraged to use make/sudo make clean install? Now from reading the responses here, it seems a logical reason was that the files via makefile are not tracked by pacman and that not knowing what the makefile does with sudo priviledges can cause issues.

@scimmia, Thanks. That's a solid reason.

Marking as solved, but further input welcome. Thank you all!

phw · 2016-10-17 08:58:19

Just adding that installing to /usr from source and having files there that are not tracked by pacman is bad practice and frowned upon. I mean people probably don't care what *you* have installed, but they know this can make problems (e.g. packaged files getting overwritten). However, if you do install from source without creating your own pacman package, /usr/local would be where you should install such packages. It is a location for user installed software in opposite to /usr which is supposed to be handled by whatever packaging your distribution uses. I think there is nothing really bad about installing to /usr/local, as long as you know what you have put there. Currently my /usr/local is empty, but I use it from time to time for such cases.

Trilby · 2016-10-17 12:07:38

Also note there is a big difference between the following sets of commands

sudo make clean install

make clean
sudo make install

Assuming you're ok with the untracked files this will leave in the target directory, the second set is perfectly fine. The first has another major problem though as it violates the principle of least privilege. You should not build software as root, you only need root/sudo to install it. But due to the way make works, if you run `sudo make install` without having built the software, it will build as root then install.

With well audited sources and Makefiles like dwm, this wouldn't do any actual harm - but it is bad practice.

EDIT: also note with root privileges given to a clean directive, you should hope nothing goes wrong. You'd be running `rm` commands as root with variables as their target. It doesn't take much to imagine how wrong this could go if for some reason those variables were imprecisely defined. In reality a few things would have to go wrong, and a few unfortunate coincidences aline for a failed clean directive run as root to do any real damage - but as there's never any need for root access for a proper clean directive, so just don't ever grant it.

frank604 · 2016-10-17 20:26:28

@phw, good point. Your response seems to follow the trend of what others have said in this thread. Thank you.

@trillby, Indeed. Good point on privileges on build vs install and rm as root to clean. I think from all these responses I'm beginning to see all the reasons why it was frowned on me.

Once again, thank you all.

Arch Linux

#1 2016-10-15 04:06:57

[Solved] General linux best-practices with makefile

#2 2016-10-15 04:31:04

Re: [Solved] General linux best-practices with makefile

#3 2016-10-15 04:38:08

Re: [Solved] General linux best-practices with makefile

#4 2016-10-15 05:28:03

Re: [Solved] General linux best-practices with makefile

#5 2016-10-15 05:35:39

Re: [Solved] General linux best-practices with makefile

#6 2016-10-15 05:42:38

Re: [Solved] General linux best-practices with makefile

#7 2016-10-15 07:29:21

Re: [Solved] General linux best-practices with makefile

#8 2016-10-17 08:58:19

Re: [Solved] General linux best-practices with makefile

#9 2016-10-17 12:07:38

Re: [Solved] General linux best-practices with makefile

#10 2016-10-17 20:26:28

Re: [Solved] General linux best-practices with makefile

Board footer