On Tue, 2011-08-02 at 17:02 +1200, Tim Penhey wrote: > > function unity-env > > { > > export PATH=~/staging/bin:$PATH > > export XDG_DATA_DIRS=~/staging/share > > export LD_LIBRARY_PATH=~/staging/lib:$LD_LIBRARY_PATH > > export LD_RUN_PATH=~/staging/lib:$LD_RUN_PATH > > export PKG_CONFIG_PATH=~/staging/lib/pkgconfig > > export PYTHONPATH=~/staging/lib/python2.7/site-packages > > } > > > > Anyone got any clues? > > It was suggested that I change the exports to include the existing > directories > when there were some, so this was updated to:
Can I just say that since we're using UDD, it's *super* easy to make new packages, so you really shouldn't have a staging build for 99.9% of your testing. No, seriously. It really is as simple as a merge of your development into the packaging branch and a "bzr builddeb" in most cases. You can make it slighly more complex to track the different tests (then you can switch between them) by incrementing the packaging revision with "dch -i". Complex scripts with environment variables are a really bad idea. You never really know what you've got installed at the end of the day, so you can't report bugs effectively. And the package manager always ensures you can get back a sane system if things go... less than perfect :-) --Ted
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Mailing list: https://launchpad.net/~ayatana-dev Post to : ayatana-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana-dev More help : https://help.launchpad.net/ListHelp