Questions about "make install"

[Mike Meyer]

On Thu, 12 Aug 2010 20:41:01 +0200
Paul Boddie <paul.boddie at biotek.uio.no> wrote:

> [Back to the list...]
> 
> Mike Meyer wrote:
> > On Thu, 12 Aug 2010 19:09:17 +0200
> > Paul Boddie <paul.boddie at biotek.uio.no> wrote:
> >   
> >   
> >> Right, so the -c is there to persuade BSD variants of the program to do 
> >> the work. On Solaris you'd probably use /usr/ucb/bin/install or whatever 
> >> with that flag. Clearly, the GNU people got fed up with the confusion 
> >> and just decided to ignore -c altogether.
> >>     
> >
> > Um, read that again: -c is the *default* behavior on BSD. To quote the
> > man page, "The -c option is only included for backwards
> > compatibility."
> 
> Right, so you'd need -c with /usr/xpg4/bin/install or whatever.

You do? So you're claiming that the -c option is an X/Open requirement?

> [...]
> 
> >> I imagine that the whole /opt thing was just something various vendors 
> >> (SuSE, perhaps) wanted, and everybody else just went along with it.
> > That's pretty much my issue with the entire FSH: it's more a
> > collection of "this is what people are doing" than a "this is the way
> > things should be done".
> Which is why people look to Debian for answers, for example. You can't 
> really complain that Debian is GNU/Linux and thus not "Unix" if they're 
> one of the parties who actually do have a coherent opinion about where 
> stuff lives.

I don't complain about Debian - I complain about GNU/Linux. The GNU
tools aren't Unix tools, and generally only embrace the Unix
philosophy insofar as they are copies of Unix tools. But my perception
of GNU/Linux has nothing to do with the complaint, which is that the
README file that ships with Mercurial is incomplete and/or wrong.

> [...]
> 
> >> But arguably the job of actually checking the system and doing the 
> >> install, particularly in a "managed" location, is not the job of a Makefile.
> >>     
> >
> > I'd say it arguably is. I install most of my *managed* packages by
> > doing "make install". Deinstallation is about a 50/50 split between
> > "pkg_delete" and "make deinstall"
> 
> Managing packages isn't about filling in the holes with stuff that 
> presumably doesn't conflict with anything else. You may have a process 
> which helps you avoid conflicts, but the "pour it into the cracks" 
> mentality could quite easily cause problems in general, which is why 
> /usr/local is presumably *this* project's response to potential problems.

Um, /usr/local has been around a lot longer than Debian. Or Linux, for
that matter. It's been the standard place for third party tools to
install themselves since v7 Unix. That's why early port/package
managers default to /usr/local.

> >> Since distutils and its descendants don't provide an uninstall option, 
> >> you're a brave man to do a straight install into /usr. One can regard 
> >> putting python into /usr/local as the big hack, particularly if FreeBSD 
> >> actually provides a package for it, unless all optional software also 
> >> goes into /usr/local on FreeBSD. But anyway, back when I was running Red 
> >> Hat 7.3 and had no hope of recent packages, I ended up installing stuff 
> >> into /usr/local precisely because it's a separate area that won't 
> >> interfere with the managed infrastructure.
> >>     
> > You missed the point that on FreeBSD, python is installed in
> > /usr/local - it's not a critical part of the system.
> 
> This is pure distribution policy and nothing more; it's not an argument 
> that the system package of Python and the manually installed instance of 
> Mercurial should reside in the same place, and they arguably shouldn't 
> on FreeBSD either, but that's another discussion.

And I disagree. Apparently, the Linux package management systems are
incomplete, in that they are incapable of dealing with software that
they didn't install (come to think of it, that's yet another headache
I've run into when building rpm's and .deb's - they really can't deal
with dependencies on software from outside the package management
system). And again, even though I think mercurial is doing things the
wrong way, I'm not trying to change that - I'm arguing that the README
file needs to include the information required to get a build to run.

> >  So doing
> > "setup.py install" there doesn't write to /usr. Even then, given
> > modern file systems and frequent snapshots, installing to /usr is no
> > big deal. I'd consider running a development system that doesn't do
> > snapshots at least hourly to be the brave action these days.
> If you're installing stuff into /usr then yes, maybe you should be 
> taking hourly snapshots.

Even if you're not, no reason not to. On a modern FS, snapshots are
fast and cheap. In particular, if nothing changes between snapshots,
the new ones don't use any space. I recommend them for any file system
that's undergoing active changes - which includes any file system
where software is being installed, whether it's always being done by a
package manager or not.

Of course, I prefer systems where software that isn't part of the
system installation doesn't go in /usr to start with. That's what
/usr/local has been for since I started working with v6 back in the
70s. Linux systems that just dump everything in their repository in
/usr are just begging for problems - and getting them, in that they
install Python in /usr instead of /usr/local while encouraging (well,
via the FHS) third party modules to be installed in /usr/local without
tweaking the Python build to make that part of the default PYTHONPATH.

> > Of course, python packages that complete the job *don't care*. They
> > figure out that they aren't on the path, and then tweak sys.path at
> > startup to be correct.
> Well, perhaps this could be an improvement made to the installation process.

This wouldn't be in the installation process, it'd be in the hg
command. It would probably require some tweaks to the installation as
well, so that the command would know where to find the required
libraries if they aren't on PYTHONPATH.

> Yes, perhaps it should. There is the assumption that people building 
> from source would read the instructions available at the location from 
> which they acquired the software, but I'll accept that such instructions 
> could also accompany the software. I'm not a big fan of doc(s) 
> directories which just tell you to "look at the Web site".

Removing everything but the "Look at the web site" instructions in the
README that comes with mercurial would be an improvement. If you're
going to include more than that, they should be complete enough that
you then don't need the web site for the things they cover.

       <mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org