On Sun, 2002-05-26 at 00:57, John Summerfield wrote:
> > On Sat, 2002-05-25 at 21:57, John Summerfield wrote:
> > > > We just finished a release so we're
> > > > breaking stuff again.
> > >
> > > While you're at it, would you lease put the version/release into the names
> > so we
> > > can have more than one version installed at the same time?
> > >
> > > So, we have anaconda-7.3 instead of anaconda in each of these:
> >
> > No, it makes it a lot harder because I have to maintain a version in the
> > path that gets appended during anaconda runtime. Which is a royal PITA
> > from a release management point of view.
>
>
> I don't understand.
See the top of the anaconda script. Specifically the part where it does
sys.path.append('/usr/lib/anaconda')
I am NOT versioning that.. it would require either having a) anaconda
not be really runnable which significantly impacts the way we work or b)
last minute changes to change the version at the very end which isn't
really acceptable either. Not to mention the many occurrences of things
which reference /usr/lib/anaconda-runtime.
> During testing? I use a variety of different accounts for that kind of thing,
> though in the particular case of anaconda that falls down. However, a script
> that sets the environment the way you want and invokes your preferred terminal
> window would be one way to manage that.
During testing or even building trees, I can work just fine from
multiple source trees which I've built in. Across multiple
architectures. Just have built source trees and you can run all of the
buildinstall stuff and the like right out of the scripts subdir.
They're smart and pull the copies in the current working directory if
they exist instead of using the ones from the anaconda-runtime in the
package tree.
Having more than one version installed is silly because it doesn't buy
you anything at all. The python files are pulled from packages, not
/usr/lib/anaconda.
Sorry, I can't see any way in which this could be helpful. Not to
mention the fact that it adds even more places for fragility in an
already too-fragile build process.
Cheers,
Jeremy
