Side-by-side install of multiple versions of packages from source into /opt
I'm reposting this from here (http://www.linuxquestions.org/questi...4/) mainly because that thread, having been marked "Solved", probably didnt get any attention.
I'd really love to have an example of how to maintain a package installed from source.
I think it would help a lot of people if there were a decent hand-holding guide for "maintaining packages installed from source".
However, I can't seem to coax Google into finding such a guide for the 2 distros I use - CentOS(server) and Ubuntu(Desktop).
As an example, there is a fine editor / dev environment, that is somehow not popular among linux users for whatever reasons, called SETEdit ( http://setedit.sourceforge.net/ ) which depends on TVision ( http://tvision.sourceforge.net/ ). It is an opensource port of the likeable old TurboPascal IDE from Borland on which a lot of devs learnt programming in university.
Now both need to be compiled from source as the latest versions of CentOS and Ubuntu dont have it (and it doesnt always work to change a distro for an editor / dev env).
So if I want to compile from source tv and setedit (setedit needs tv installed to display the widgets that make up setedit), and I also want to be able to future-proof my installs by allowing for multiple versions of both, then is this the way to do it, roughly...
Then it would install set0.5.4 in /opt/set0.5.4
( I think I might have missed a step in telling the installation of set0.5.4 that it should pick up tv2.0.3 from /opt/tv2.0.3 )
Now imagine, after 6 months, tv project realeases an updated version tv2.0.4 and that actually breaks a nice feature X in set0.5.4.
But I want tv2.0.4 for some crucial updates, but I also want my set0.5.4 working fine as it has been.
So this time, I repeat the above steps, but with new locations.
I make-make-install tv2.0.4 to /opt/tv2.0.4 and I compile set0.5.4 (same old version) with tv2.0.4 (which removes feature SetX, but adds some nice bling to tv widgets thmeselves) telling it to pick up tv from /opt/tv2.0.4.
This new set version I install into /opt/set0.5.4-1
So now I have :
This would be really really neat.
I looked it up and find that there is a distro that does this: Gobolinux
But alas! I have to use Centos on server, and Ubuntu on desktop, for several reasons.
So switching to Gobolinux is out of question.
The other option I have is using portable linux apps, but that is a long learning curve and a whole project in itself, not a day's work.
So, can I pull off the above?
I have faced this scenario a couple of times for packages far more important than setedit - where the single piece of software absolutely essential for the server is not in the official repos or installing other repos isnt allowed.
If this multiple-version side-by-side /opt solution works, that would be the best thing to happen to me in Linux in some time, and solve a lot of maintenance issues.
Note that I also dont have to bother uninstalling an obsolete version from /opt - I just install a new version and simply don't use the old one!
Is it better to use /usr/local for this purpose or /opt ? I personally think not, because /opt seems cleaner and further away from the distro-maintained core sytem than /usr/local. The further away any custom things, the better, I think.
Another possiblity that struck me on some thought is why not simply create a /home/user/bin and install both tv and set into it - as so:
And then, adding /home/user/bin to the system path...
That way absolutely nothing is touched in the core system.
Would this way - /home/user/bin work with a server package - like say a web proxy server - nginx / squid / lighttpd / etc?
Or do these simply have to be installed into /opt, /usr/local at best, and from the native package manager at worst?
If I could locally install and compile from source into /home/user/bin/nginx-x.y.A, /home/user/bin/nginx-x.y.B, etc. I could easily test multiple versions and configurations while being fully assured that I broke nothing in the server!
That would be a great thing.
Apologies for the long post, but this is couldn't possibly have been shortened (without making it decently google-searchable)
Thanks in advance!
CentOS6.3 ( the current) you will have some problems with documentation
they assume that you ALREADY know how to admin a RHEL install
now the centwiki has a lot but cent relies on the red hat documents
RHEL is a VERY "Conservative" distro and as such has a lot of OLD software in it
OLD but updated with bug and security fixes
but often different( and newer) versions of software need installing
/opt is fine BUT care dose need to be taken so that the operating system CAN NOT FIND conflicting versions
for example "gimp-2.6.9-4.el6_3.3.x86_64.rpm" is in the el6 updates
build gimp2.8 on centos6.3
-- not an easy task , but good practice .And a task that could kill the CentOS install if not done carefully--
there are conflicting almost EVERYTHING
look for tutorials for building the gimp DEVELOPMENT versions
the testing gimp-development version is often WAY TOO NEW even for the current fedora release
"build folders" are a bit of a norm for things like the above
this example has incompatible versions of many things
for example gtk is DIFFERENT from the version in cent
you would built and install the NEW gtk to /opt/gimp2.8
and export that location for building programs that need it
-- this is where BUILD SCRIPTS come in --
the "./configure" line becomes a 300 line command very fast
that thing is old the front page mentions the difference in gcc2 to gcc 3
gcc 4.7 is current and gcc 2 is from the `90's
0.5.7 Fedora 14 - unsupported
-- the source --
0.5.7 r1294 Tarball (Source)
should ??? build on centOS using the OLD compat-gcc-34-3.4.6-19.el6.i686.rpm
i highly dought that it would build in the default gcc4.4 in cent6.3
you are aware that CentOS uses Gedit by default
and that VI is in the repos along with Emacs
I would recommend learning to use VI and Emacs
Thanks for going through all that and replying so quickly.
I found some good links from what you suggested:
However none much from the Centos/RHEL docs - they just contain tables of version numbers of various packages. But I found some decent looking howto's on make and configure, which I plan to go through.
Also, as you said:
SETEdit, TVision and RHIDE, an IDE made out of using those 2 packages, all are built on gcc2 and gcc3. This is a relevant mailing list post from RHIDE-users:
As also this: http://sourceforge.net/mailarchive/f...=setedit-users
Nothing since 2009 !!
So I guess for SETedit either have to contact the author or get into the source (not easy!)
When GNOME/KDE is available, I use Geany / Eclipse / Kate / Kdewebdev.
But sometimes I need to edit huge source files on the server itself (yes, bad practice, I know)
Moving away from editors, to the second part of my question:
Suppose I want to try out 2-3 different versions of a server package like Nginx, would it hurt to build them in /home/user/bin/nginx-x.y.A, /home/user/bin/nginx-x.y.B etc?
This last question is a bit pressing for me, so I'll be happy if you could tell me a bit about it. I don't want to try something and break my running install of CentOS!
|All times are GMT -5. The time now is 11:17 PM.|