'sudo make install' doesn't work #1717

New Issue

tahoe-lafs · 2012-04-12T15:11:27Z

davidsarah commented

2012-04-12 15:11:27 +00:00

erpo41 wrote on volunteergrid2-l:

Hi all,

Since my node seems stable, I'm beginning to upload my backups into
the grid. Since tahoe is running on a dedicated server in its own user
account, I need to make the tahoe executable available to my personal
user account on that server. (Previously I had been running tahoe out
of /home/volunteergrid2/allmydata-tahoe-1.9.1/bin.)

When I tried to install tahoe, I got the following error messages:

  eric@io:/home/volunteergrid2/allmydata-tahoe-1.9.1$ sudo make install
  python ./setup.py install --single-version-externally-managed
  running update_version
  no version-control data found, leaving _version.py alone
  running install
  error: You must specify --record or --root when building system packages
  make: *** [install] Error 1

This is why I hate building/installing from source on Linux. What do
--record and --root do? Does "building system packages" refer to
building the executable or a deb/rpm package? Do I actually have to go
back and rebuild the tahoe executable with those options? If so, where
do I insert those options in the "python setup.py build" command line
recommended by quickstart.rst for building the executable? What do
those options do and what should I set them to on my system?

The 'install' Makefile target should not be using
--single-version-externally-managed.

As a workaround, use 'sudo python ./setup.py install'.

erpo41 wrote on volunteergrid2-l: > Hi all, > > Since my node seems stable, I'm beginning to upload my backups into > the grid. Since tahoe is running on a dedicated server in its own user > account, I need to make the tahoe executable available to my personal > user account on that server. (Previously I had been running tahoe out > of /home/volunteergrid2/allmydata-tahoe-1.9.1/bin.) > > When I tried to install tahoe, I got the following error messages: ``` eric@io:/home/volunteergrid2/allmydata-tahoe-1.9.1$ sudo make install python ./setup.py install --single-version-externally-managed running update_version no version-control data found, leaving _version.py alone running install error: You must specify --record or --root when building system packages make: *** [install] Error 1 ``` > This is why I hate building/installing from source on Linux. What do > --record and --root do? Does "building system packages" refer to > building the executable or a deb/rpm package? Do I actually have to go > back and rebuild the tahoe executable with those options? If so, where > do I insert those options in the "python setup.py build" command line > recommended by quickstart.rst for building the executable? What do > those options do and what should I set them to on my system? The 'install' Makefile target should not be using `--single-version-externally-managed`. As a workaround, use '`sudo python ./setup.py install`'.

tahoe-lafs added the

labels 2012-04-12 15:11:27 +00:00

tahoe-lafs added this to the undecided milestone 2012-04-12 15:11:27 +00:00

zooko commented

2012-04-12 18:40:28 +00:00

I'd like to remove the "make install" target, so that when a user runs sudo make install they get some nice default error message from make saying that there is no such target. That way I won't have to spend my time supporting it, and nor will other programmers like Brian.

Brian: what do you say? Remove it, let them get an error message from make, then hopefully they'll look around for a "README" or look at the web site, find source:docs/quickstart.rst, and go from there.

I'd like to remove the "make install" target, so that when a user runs `sudo make install` they get some nice default error message from `make` saying that there is no such target. That way I won't have to spend my time supporting it, and nor will other programmers like Brian. Brian: what do you say? Remove it, let them get an error message from `make`, then hopefully they'll look around for a "README" or look at the web site, find source:docs/quickstart.rst, and go from there.

warner was assigned by zooko

2012-04-12 18:40:28 +00:00

davidsarah commented

2012-04-12 18:44:53 +00:00

I asked:

Does this workaround [sudo python setup.py install] work on your system?

erpo41 replied:

Thanks for the suggestion! That command did install the tahoe executable in /usr/local/bin/tahoe, but when I try to run it I get this:

eric@io:/srv/volunteergrid2$ tahoe
Traceback (most recent call last):
  File "/usr/local/bin/tahoe", line 6, in <module>
    from pkg_resources import load_entry_point
  File "/usr/lib/python2.6/dist-packages/pkg_resources.py", line 2655,
in <module>
    working_set.require(__requires__)
  File "/usr/lib/python2.6/dist-packages/pkg_resources.py", line 648, in require
    needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python2.6/dist-packages/pkg_resources.py", line 546, in resolve
    raise DistributionNotFound(req)
pkg_resources.DistributionNotFound: pycryptopp>=0.5.20

I'm guessing that tahoe depends on a lot of external libraries that weren't installed along with the executable when I ran that command.

That's correct.

As a workaround, I copied the /home/volunteergrid2/allmydata-1.9.1 directory to /home/eric, reset the directory ownership, and symlinked the executable into /home/eric/bin. Now I have tahoe for my user account, which is all I really needed anyway.

I asked: > Does this workaround [`sudo python setup.py install`] work on your system? erpo41 replied: > Thanks for the suggestion! That command did install the `tahoe` executable in `/usr/local/bin/tahoe`, but when I try to run it I get this: ``` eric@io:/srv/volunteergrid2$ tahoe Traceback (most recent call last): File "/usr/local/bin/tahoe", line 6, in <module> from pkg_resources import load_entry_point File "/usr/lib/python2.6/dist-packages/pkg_resources.py", line 2655, in <module> working_set.require(__requires__) File "/usr/lib/python2.6/dist-packages/pkg_resources.py", line 648, in require needed = self.resolve(parse_requirements(requirements)) File "/usr/lib/python2.6/dist-packages/pkg_resources.py", line 546, in resolve raise DistributionNotFound(req) pkg_resources.DistributionNotFound: pycryptopp>=0.5.20 ``` > I'm guessing that tahoe depends on a lot of external libraries that weren't installed along with the executable when I ran that command. That's correct. > As a workaround, I copied the `/home/volunteergrid2/allmydata-1.9.1` directory to `/home/eric`, reset the directory ownership, and symlinked the executable into `/home/eric/bin`. Now I have tahoe for my user account, which is all I really needed anyway.

davidsarah commented

2012-04-12 18:45:39 +00:00

Replying to zooko:

I'd like to remove the "make install" target, so that when a user runs sudo make install they get some nice default error message from make saying that there is no such target. That way I won't have to spend my time supporting it, and nor will other programmers like Brian.

+1. It appears this user didn't actually want a system install, anyway.

Replying to [zooko](/tahoe-lafs/trac-2024-07-25/issues/1717#issuecomment-88210): > I'd like to remove the "make install" target, so that when a user runs `sudo make install` they get some nice default error message from `make` saying that there is no such target. That way I won't have to spend my time supporting it, and nor will other programmers like Brian. +1. It appears this user didn't actually want a system install, anyway.

warner commented

2012-04-12 20:21:10 +00:00

Yeah, I'm ok with removing "make install", as long as packagers aren't using it.

The original idea with "make install", which existed long before we started using setuptools, was to make traditional autoconf/unix-style build/install commands work. In that world (my homeland, you might say) "make; sudo make install" is all you need to put things in the right place. And "make install PREFIX=/xyz" was the right way to install it somewhere other than /usr/local, which was convenient for packagers (where /xyz was usually ./temp-pkg-dir and got tarred up and turned into a distribution package).

That PREFIX=/xyz didn't work with "setup.py install" once setuptools came to call, because it insists upon the installation directory already being in your PYTHONPATH, and also installed that weird .pkg-info metadata (at least I considered it weird at the time). So I added those extra flags to the Makefile both to remind myself of what they were, and to allow "make install PREFIX=" to be useful to packagers that wanted the traditional interface.

If our packagers are all using setuptools-native commands (some form of setup.py install that points to a local directory), then we can remove the "make install" target. The current ubuntu packaging (http://archive.ubuntu.com/ubuntu/pool/universe/t/tahoe-lafs/tahoe-lafs_1.8.3-2.debian.tar.gz) appears to use this:

python setup.py install \
 --no-compile --install-layout=deb \
 --single-version-externally-managed \
 --root $(CURDIR)/debian/$(package)

(i.e. what 'make install PREFIX=' used to do). So they won't be affected. We should check with the other packagers to make sure this won't impact them, but if so, they should really switch to the ubuntu scheme.

Yeah, I'm ok with removing "make install", as long as packagers aren't using it. The original idea with "make install", which existed long before we started using setuptools, was to make traditional autoconf/unix-style build/install commands work. In that world (my homeland, you might say) "make; sudo make install" is all you need to put things in the right place. And "make install PREFIX=/xyz" was the right way to install it somewhere other than /usr/local, which was convenient for packagers (where /xyz was usually ./temp-pkg-dir and got tarred up and turned into a distribution package). That PREFIX=/xyz didn't work with "setup.py install" once setuptools came to call, because it insists upon the installation directory already being in your PYTHONPATH, and also installed that weird .pkg-info metadata (at least I considered it weird at the time). So I added those extra flags to the Makefile both to remind myself of what they were, and to allow "make install PREFIX=" to be useful to packagers that wanted the traditional interface. If our packagers are all using setuptools-native commands (some form of `setup.py install` that points to a local directory), then we can remove the "make install" target. The current ubuntu packaging (<http://archive.ubuntu.com/ubuntu/pool/universe/t/tahoe-lafs/tahoe-lafs_1.8.3-2.debian.tar.gz>) appears to use this: ``` python setup.py install \ --no-compile --install-layout=deb \ --single-version-externally-managed \ --root $(CURDIR)/debian/$(package) ``` (i.e. what 'make install PREFIX=' used to do). So they won't be affected. We should check with the other packagers to make sure this won't impact them, but if so, they should really switch to the ubuntu scheme.

daira commented

2013-05-26 22:10:16 +00:00

Pull request at https://github.com/tahoe-lafs/tahoe-lafs/pull/44.

Pull request at <https://github.com/tahoe-lafs/tahoe-lafs/pull/44>.

tahoe-lafs added

normal

and removed

major

labels 2013-05-26 22:10:16 +00:00

tahoe-lafs modified the milestone from undecided to 1.11.0

2013-05-26 22:10:16 +00:00

daira commented