From: Paul S. <ps...@ne...> - 2006-10-25 18:57:29
|
Hi all; I can't find any info on the homepage, FAQ, README, etc. on where to post bugs so I'm guessing I just send them here...? I just downloaded and tried to install FUSE 2.6.0 with a DESTDIR set (I'm actually trying to cross-compile it for an embedded target on a different architecture). Mostly it worked fine, but at the very end it fails: /usr/sbin/update-rc.d fuse start 34 S . start 41 0 6 . update-rc.d: /etc/init.d/fuse: file does not exist make[2]: *** [install-exec-local] Error 1 Obviously /etc/init.d/fuse doesn't exist, because I used DESTDIR to install it somewhere else. This code is in utils/Makefile.am:install-exec-local. I really strongly feel that a normal "make install" should NOT be running update-rc.d commands to install links. To me that violates the Principle of Least Surprise. In fact, installing the script into init.d in the first place is unusual: for example, using an INIT_D_PATH which isn't based on PREFIX seems odd to me, although I understand the reason for it. I think these kinds of oddities are why most autoconf packages don't try to install startup scripts using their makefile targets, but rather leave the installation of the startup to the packagers and their tools (RPM, DPKG, etc.) Consider Ubuntu Edgy (6.10) which is the beginning of a migration away from SysV init altogether! Or, in my setup, I'm using BusyBox and don't have sysv init scripts, and I don't want this at all. If you really want to keep this capability in the makefiles, then here are a few thoughts about possible fixes/enhancements: * A separate target ("install-sysv" ?) could be created that did this stuff, and normal "install" wouldn't do it. * A configure option could be created that would turn this off. * The install-exec-local rule could test DESTDIR and only run update-rc.d if it was empty. * Provide some kind of make variable that, if set, would turn off this install, so people like me can run "make SETUP_INIT=false" or similar. Thanks for listening; Cheers! -- ----------------------------------------------------------------------------- Paul D. Smith <ps...@ne...> http://netezza.com "Please remain calm--I may be mad, but I am a professional."--Mad Scientist ----------------------------------------------------------------------------- These are my opinions--Netezza takes no responsibility for them. |
From: Miklos S. <mi...@sz...> - 2006-10-25 19:17:31
|
> I can't find any info on the homepage, FAQ, README, etc. on where to > post bugs so I'm guessing I just send them here...? This is the right place. > I just downloaded and tried to install FUSE 2.6.0 with a DESTDIR set > (I'm actually trying to cross-compile it for an embedded target on a > different architecture). Mostly it worked fine, but at the very end it > fails: > > /usr/sbin/update-rc.d fuse start 34 S . start 41 0 6 . > update-rc.d: /etc/init.d/fuse: file does not exist > make[2]: *** [install-exec-local] Error 1 > > Obviously /etc/init.d/fuse doesn't exist, because I used DESTDIR to > install it somewhere else. > > This code is in utils/Makefile.am:install-exec-local. I really strongly > feel that a normal "make install" should NOT be running update-rc.d > commands to install links. Right, it could instead print instructions on how to set up the symlinks. OTOH, people do expect "make install" to just do everything automatically, and rarely read the installation instructions, unless things go wrong. > To me that violates the Principle of Least Surprise. In fact, > installing the script into init.d in the first place is unusual: for > example, using an INIT_D_PATH which isn't based on PREFIX seems odd > to me, although I understand the reason for it. I think these kinds > of oddities are why most autoconf packages don't try to install > startup scripts using their makefile targets, but rather leave the > installation of the startup to the packagers and their tools (RPM, > DPKG, etc.) Consider Ubuntu Edgy (6.10) which is the beginning of a > migration away from SysV init altogether! Or, in my setup, I'm > using BusyBox and don't have sysv init scripts, and I don't want > this at all. > > If you really want to keep this capability in the makefiles, then here > are a few thoughts about possible fixes/enhancements: > > * A separate target ("install-sysv" ?) could be created that did > this stuff, and normal "install" wouldn't do it. > * A configure option could be created that would turn this off. > * The install-exec-local rule could test DESTDIR and only run > update-rc.d if it was empty. I think I'll go for this. Thanks for the report. Miklos |
From: Paul S. <ps...@ne...> - 2006-10-26 15:34:20
Attachments:
20_fuse_util_mount.fuse
|
On Wed, 2006-10-25 at 21:17 +0200, Miklos Szeredi wrote: > OTOH, people do expect "make install" to just do everything > automatically, and rarely read the installation instructions, unless > things go wrong. Understand. Nevertheless, any package maintainer will want to manage all this kind of thing themselves. I really feel that the "runtime install" should be separable (maybe as a different make rule) from the "build time install", if you see what I mean. > > > > * The install-exec-local rule could test DESTDIR and only run > > update-rc.d if it was empty. > I think I'll go for this. Note there are other things which are in a similar vein, although they don't cause make errors. Examples: running mknod (requires root privileges, which most people building embedded systems don't have/want), and hardcoding installs of /etc/init.d/fuse (not all systems use sysv init). One other thing: the mount.fuse script relies on /bin/bash, which is a problem for embedded systems based on BusyBox, etc. where bash is typically not installed. I tweaked the script to use /bin/sh and simple sed commands that appear in the BusyBox version of sed (and so should work on all versions). Patch attached. This patch has one tiny difference from the original behavior: if $1 contains multiple # chars the original would put the extra ones in the FSTYPE value and none in the MOUNTPATH value; my patch reverses this so FSTYPE doesn't have any # and any # beyond the first appear in the MOUNTPATH value. Cheers! > Thanks for the report. Thanks for FUSE! :-) -- ----------------------------------------------------------------------------- Paul D. Smith <ps...@ne...> http://netezza.com "Please remain calm--I may be mad, but I am a professional."--Mad Scientist ----------------------------------------------------------------------------- These are my opinions--Netezza takes no responsibility for them. |
From: Miklos S. <mi...@sz...> - 2006-10-26 19:02:35
|
> > OTOH, people do expect "make install" to just do everything > > automatically, and rarely read the installation instructions, unless > > things go wrong. > > Understand. Nevertheless, any package maintainer will want to manage > all this kind of thing themselves. That's true. Actually the solution I chose is just to ignore errors from the update-rc.d invocation. > I really feel that the "runtime install" should be separable (maybe > as a different make rule) from the "build time install", if you see > what I mean. > > > > > > > * The install-exec-local rule could test DESTDIR and only run > > > update-rc.d if it was empty. > > > I think I'll go for this. > > Note there are other things which are in a similar vein, although they > don't cause make errors. Examples: running mknod (requires root > privileges, Hmm, why does this not cause make failure? Strange. > which most people building embedded systems don't have/want), and > hardcoding installs of /etc/init.d/fuse (not all systems use sysv > init). > > One other thing: the mount.fuse script relies on /bin/bash, which is a > problem for embedded systems based on BusyBox, etc. where bash is > typically not installed. I tweaked the script to use /bin/sh and simple > sed commands that appear in the BusyBox version of sed (and so should > work on all versions). Patch attached. This patch has one tiny > difference from the original behavior: if $1 contains multiple # chars > the original would put the extra ones in the FSTYPE value and none in > the MOUNTPATH value; my patch reverses this so FSTYPE doesn't have any # > and any # beyond the first appear in the MOUNTPATH value. Thanks, applied your patch. Miklos |
From: Paul S. <ps...@ne...> - 2006-10-26 19:09:26
|
On Thu, 2006-10-26 at 21:02 +0200, Miklos Szeredi wrote: > > Note there are other things which are in a similar vein, although they > > don't cause make errors. Examples: running mknod (requires root > > privileges, > > Hmm, why does this not cause make failure? Strange. It probably would; I ran this under fakeroot so that undoubtedly masked the error. Not everyone uses fakeroot tho. Cheers! -- ----------------------------------------------------------------------------- Paul D. Smith <ps...@ne...> http://netezza.com "Please remain calm--I may be mad, but I am a professional."--Mad Scientist ----------------------------------------------------------------------------- These are my opinions--Netezza takes no responsibility for them. |