Before I learned how to compile CVS, my major concern was "How can I keep the stable version and CVS installed at the same time on linux." This was, of course, no trouble because the stable version was installed to /usr/bin/ and the CVS version was installed to /usr/local/bin/. The reason I had worried was the autopackage nightly builds. When I installed an autopackage it installed in the place of the stable version.
Having both versions has been a good experience. It is a safety net. If a old feature breaks in CVS it is likely I can still use that feature in the stable version. Best of all I can do this without having to revert to an earlier version by uninstalling and reinstalling.
As long as I was pestering Mike Hearn with my naive questions about building the autopackage, I decided to ask him if there was a way the packaging system could handle the issue and give users the ability to keep side-by-side installs. Mike suggested that the best solution might be to build a different executable for CVS i.e. inkscape-cvs instead of inkscape. This sounds reasonable to me. For instance, the sylpheed mail client has a sister project that builds the experimental sylpheed-claws version.
The usability of CVS is definately one of Inkscape's strengths. I think the smaller the barrier between new users and CVS the better.
Comments?
Aaron Spike
Aaron and Sarah Spike wrote:
Before I learned how to compile CVS, my major concern was "How can I keep the stable version and CVS installed at the same time on linux." This was, of course, no trouble because the stable version was installed to /usr/bin/ and the CVS version was installed to /usr/local/bin/. The reason I had worried was the autopackage nightly builds. When I installed an autopackage it installed in the place of the stable version.
Having both versions has been a good experience. It is a safety net. If a old feature breaks in CVS it is likely I can still use that feature in the stable version. Best of all I can do this without having to revert to an earlier version by uninstalling and reinstalling.
I go one step farther, and put Inkscape in its own installation directory, with ./configure --prefix=/usr/local/inkscape ...blah....
This gives it its own directory, leaving everything else in /usr and /usr/local alone. And deleting it later is trivial.
Bob
Hello.
On 6/10/05, Bob Jamison <rwjj@...127...> wrote:
Aaron and Sarah Spike wrote:
Having both versions has been a good experience. It is a safety net. If a old feature breaks in CVS it is likely I can still use that feature in the stable version. Best of all I can do this without having to revert to an earlier version by uninstalling and reinstalling.
I go one step farther, and put Inkscape in its own installation directory, with ./configure --prefix=/usr/local/inkscape ...blah....
[...]
I used to have different Inkscape versions as in: /opt/inkscape-0.38 /opt/inkscape-0.39cvs /opt/inkscape-etc with a link to my current Inkscape like: /opt/inkscape -> /opt/inkscape-0.39cvs
With /opt/inkscape in my $PATH, it was easy to change to whatever version I needed to test.
Greetings!
Daniel Díaz yosoy@...31...
participants (3)
-
Aaron and Sarah Spike
-
Bob Jamison
-
Daniel Díaz