for an eg "blastwave", how to support TWO versions of a package?

David Combs

unread,

Dec 14, 2009, 2:24:01 PM12/14/09

to

subj: for a "blastwave", opencsw, ... type of site,
how to support TWO or three or four versions of a package?

(Like four versions of gnu-emacs, ancient to beta!)

How would YOU implement that ability.

Suppose libraries are different (or even incompatible!).

(Blastwave currently has only ONE version of each package.)

THANKS!

David

Richard B. Gilbert

unread,

Dec 14, 2009, 2:37:44 PM12/14/09

to

You could use an O/S like OpenVMS which supports file versioning and has
for almost thirty years. Of course at some point you have to clean up
and remove the oldest versions of things.

In a Unix or Unix-like environment you could have:
mumble.dat.v4
mumble.dat.v3
mumble.dat.v2
mumble.dat.v1

Simon Clubley

unread,

Dec 15, 2009, 8:08:43 AM12/15/09

to

On 2009-12-14, Richard B. Gilbert <rgilb...@comcast.net> wrote:
> David Combs wrote:
>> subj: for a "blastwave", opencsw, ... type of site,
>> how to support TWO or three or four versions of a package?
>>
>> (Like four versions of gnu-emacs, ancient to beta!)
>>
>> How would YOU implement that ability.
>>
>> Suppose libraries are different (or even incompatible!).
>>
>> (Blastwave currently has only ONE version of each package.)
>>
>

> You could use an O/S like OpenVMS which supports file versioning and has
> for almost thirty years. Of course at some point you have to clean up
> and remove the oldest versions of things.
>
> In a Unix or Unix-like environment you could have:
> mumble.dat.v4
> mumble.dat.v3
> mumble.dat.v2
> mumble.dat.v1
>

While it would be nice to see multiple file version support on Unix,
this isn't the problem the OP is talking about.

The OP's problem is how can you have multiple versions of a software
package, which will typically have lots of files associated with it,
installed at the same time and to have the ability to easily switch
between them.

I have the same problem (on Linux, not Solaris), but for all the packages
I have the problem with, I can build from source. My solution is to have
a dedicated /apps partition and I encode the version of the package into
the installation directory while I am building it.

Ie: ./configure --prefix=/apps/exe-emacs-21.3

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980's technology to a 21st century world

David Combs

unread,

Dec 16, 2009, 2:58:16 PM12/16/09

to

In article <hg81oq$pph$1...@news.eternal-september.org>,

Yep, makes sense.

And again, I sure wish opencsw had used /opt/opencsw!

David

John D Groenveld

unread,

Dec 16, 2009, 5:22:09 PM12/16/09

to

In article <hgbe4n$8m$2...@reader1.panix.com>,

David Combs <dkc...@panix.com> wrote:
>And again, I sure wish opencsw had used /opt/opencsw!

The Solaris package database would have name collisions.

John
groe...@acm.org

David Combs

unread,

Dec 17, 2009, 1:12:19 AM12/17/09

to

In article <hgbmih$g85k$1...@tr22n12.aset.psu.edu>,

John, could you please explain that a bit.

The reason behind proposing or wishing-for *separate*
directory-trees for blastwave and opencsw was to AVOID
that.

....

Ah, I got it. Those *SOLARIS* package-commands -- both blastwave
and opencsw call into THOSE routines?

Hmmm.

Doesn't gnu have something like a package database -- one
*could* install it TWICE, giving two *separate* data-bases?

One disadvantage is that the same piece of software might end
up be xn all three, say: .../opt/{sunfreeware,csw,optncsw)?

I mean, disk has surely gotten a lot more affordable these
days (and how!, compared to 20 yrs ago).

So I think I now understand.

David