Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (athena.apache.org: domain of aconway@redhat.com designates
 209.132.183.28 as permitted sender)
Message-ID: <1398954588.2473.88.camel@localhost>
Subject: Proton installer - its all good.
From: Alan Conway <aconway@redhat.com>
To: users <users@qpid.apache.org>
Date: Thu, 01 May 2014 10:29:48 -0400
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

WARNING: this email contains Unsolicited Advice. Viewer discretion
advised.

In summary: I'm happy with the proton installer. The debate is due to
two distinct use cases, I'm OK with covering both. Let me summarize the
use cases and give some Unsolicited Advice which you are free to ignore
or not even read.

1. I want to install proton and have it Just Work. I have root access,
this is my personal machine, I don't care if I (accidentally or
deliberately) over-write files in /usr or other places where
interpreters are installed. Frankly I have more important things to do
than puzzle over arcane Unix trivia like environment settings and
standard directory structures, I'm busy! -DSYSINSTALL_BINDINGS is for
you!

2. I want multiple separate install trees, each containing software
versions that work together (e.g. proton+qpid). I _need_ to separate
software installed by my system installer (yum, apt...) from software
from other sources, e.g. source-built (I use /usr/local). I may create
other trees in my home dir, without root permission, for testing
purposes. I'm ok with setting PATH, PYTHONPATH and LD_LIBRARY_PATH to
choose which tree(s) to work with (usually you can avoid
LD_LIBRARY_PATH). I can set system wide and per-user defaults or use
specific environment scripts. Maybe I administer a shared machine or
maybe I'm just fussy about my own.

I understand the motivation for both use cases, I've certainly done both
myself. I think the current installer works for both. There are minor
tweaks that could improve 2. but that should be expressed as a patch not
more email.

UNSOLICITED ADVICE:

FYI: Here's why I recommend 2. (which IMO is standard Unix practice) for
long term sanity, even though 1. can be quicker in the short term. 

You download the latest proton trunk and do install type 1. as root.
Maybe you install it directly in /usr, maybe in /usr/local. You start
your project using latest latest proton features. It works. Hurray! Some
files got installed in /usr (which you maybe didn't notice if you
thought you installed in /usr/local.) but you don't care, that's what
makes it work!!

Later, you install unrelated application foo using your system installer
or even better, it gets automatically updated by your system's automated
updater. It works! Unnoticed by you, foo has a dependency on
qpid-proton-0.X (some ways behind trunk) so the installer helpfully
installs it for you in /usr.

You return to your proton project. Nothing works! What the... I didn't
change anything!!!??!? Whaddya mean "no such function"? That function is
clearly in the proton source code that I built and installed earlier
dammit. Finally you wipe your build clean, rebuild and re-install. It
works. Hurray! But you have an uneasy feeling...

The next morning, you fire up application foo. Nothing works! What
the..., it worked yesterday??!?!?! You re-install foo. Nothing works
(your system installer still thinks qpid-proton-0.X is installed so
doesn't re-install it when you re-install foo) You search for where foo
logs its @!#!#@!# error message, tear your hear, curse the gods  - you
get the picture.

This is stuff that has happened to me more than once (I'm a slow
learner.) I don't judge: Option 1. can work in the right circumstances
so if it works for you then go for it. They day your proton project
stops working for no reason, or some totally unrelated app starts
spewing proton-related error messages (if you're lucky) remember this
mail.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org