On Mon, Apr 28, 2014 at 5:40 PM, Justin Ross <[email protected]> wrote:
> On Mon, Apr 28, 2014 at 4:55 PM, Gordon Sim <[email protected]> wrote: > > > On 04/28/2014 09:30 PM, Justin Ross wrote: > > > >> On Mon, Apr 28, 2014 at 4:27 PM, Gordon Sim <[email protected]> wrote: > >> > >>> Can SYSINSTALL_BINDINGS=ON not be automatically inferred if no > >>>>> CMAKE_INSTALL_PREFIX is specified? Or does CMAKE_INSTALL_PREFIX > always > >>>>> have > >>>>> a value, even if not set explicitly? > >>>>> > >>>>> > >>>>> That would overwrite OS-reserved file locations. > >>>>> > >>>> > >>>> > >>> That's what make install (without an explicit prefix) always does, > isn't > >>> it? > >>> > >>> If I don't specify a prefix, I expect things to be installed into the > >>> system wide default locations for whatever it is. If I specify a > prefix, > >>> I > >>> expect to to be relative to that and expect to have to set various path > >>> variables to locate 'my' install. > >>> > >>> > >>> No, the default prefix is typically /usr/local, and indeed /usr/local > is > >> set aside for this use. For instance, setup.py install by default > >> installs > >> with the prefix /usr/local on unix machines. > >> > > > > Yes, I wasn't suggesting changing the default. > > > > So are you saying that SYSINSTALL_BINDINGS doesn't use the 'default', but > > overrides that? If so then I agree with Fraser that the language in the > > warning is confusing. (Since it sounds like the 'non-standard 'approach > is > > used by default unless the 'standard' one is explicitly selected. > > > There are differing ideas about what the "default" means. > > SYSINSTALL_BINDINGS=ON means "query the interpreter for its standard > library location". "The interpreter" is whatever happens to be on the path > at the time the query is performed. The queried location is *not* modified > for any prefix value you may have specified. > > If you do this on a fresh Fedora install using Python, the query returns > something like /usr/lib64/python2.7/site-packages/. As you know, this is > an OS-reserved location. If you "sudo make install" to this location, you > can easily overwrite packager-installed files. > To be fair it isn't terribly difficult to overwrite packager-installed files whenever you do a make install as root with any software. This really has less to do with the behaviour of the build system and more to do with unix filesystem conventions and search paths. The typical unix filesystem and interpreter conventions don't really provide a way to isolate packaged software from locally built software while still integrating them together. In fact if you're installing from source odds are you are either testing a release tarball or you need a fix which hasn't yet been packaged. Either way you are going to want to install into the "OS-reserved" location. I think these scenarios are pretty fundamental regardless of what the build system does by default, and it's certainly *not* the responsibility of the build system to prevent this or even to make it harder. A lot of engineering goes into package managers to allow this to happen with relative safety. Rpm keeps a database with a digest of every managed file and provides tools to verify and fix any of those files that get modified in ways they shouldn't be. > When I discovered this behavior was turned on by default (and had spread to > the cpp tree), I complained vociferously. Rafi is eager to keep this > behavior (me, not so much). I'm most concerned that it not be the thing > that happens by default. > What I'm eager to keep is the simple three step install process that works robustly regardless of the details of a given system's configuration. It doesn't have to work the way it currently does, it just needs to be equivalently simple and robust. > > The "default", IMO, should be what I think you're referring to: the > standard library path for a given language, but one modified for a safe > prefix reserved for locally installed modules. In the case of Python, this > would be /usr/local/lib64/python2.7/site-packages/ on my system. > > Finally, I agree with you and Fraser about the warning. I think it makes > it look like something weird is happening, but really we're hewing closer > to what I consider normal behavior. > As I said before the point of the warning is that the default behaviour is changing from previous releases. The next release won't have any warning. I did point out the change in behaviour several RC's ago and I asked that people review the new install process and especially the README which describes the new behaviour in detail. It would have been nice if this happened before voting through the 0.7 release, but better late than never I suppose. On a final note/rant, I think stuff we've built at qpid has historically had a pretty consistently terrible out of the box experience, and I would guess this is largely due to the fact that as developers we (myself included) rarely take the time to experience the install/setup from a user perspective. Most of the requirements I see motivating build/install system changes are driven from rpm or CI build requirements, which are certainly important, but not primary. One of the reasons I'm quite eager to keep the simple three step install process is that I've been forced to go through the full install/setup procedure on a bunch of different systems (fedora, ubuntu, debian, rhel, including different versions of each and different mixes of locally built vs packaged software), and as such I have a first hand appreciation for its value. Obviously things are where they are for the 0.7 release and that won't change, but for those of you who feel strongly about this, I would encourage you to step through the install/setup process yourself *before* the 0.8 release. With docker it is trivially easy now to try it on pretty much any variety of linux with any sort of custom local changes you want to play with. --Rafael
