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
