I was trying to get octave to work, and figured it needed gnuplot which needed gnuplot-nox which needed to be installed via Fink. I have usually stuck to using homebrew for my package installs.
Are there any problems with having homebrew as your primary package manager while using Fink for installing certain specific packages? Do they ever conflict? Does it make the system unstable?
Homebrew and Fink can coexist, but you need to be careful about not making a mess. In particular, since Homebrew usually builds from source, it could be a problem if you accidentally link Homebrew formulas^Wformulae against Fink-installed software, because the next upgrade might break the dependency. (That problem is probably much less likely now with Homebrew's superenv.) Basically, you need to do the job of the package manager yourself.
That said, Homebrew has an octave formula in the homebrew/science tap, so maybe you could just use that.
Related
I have a RHEL system which by default was running Python2.7 and Python3.4
I needed Python3.6 for a project I wanted to work on and so I downloaded it and built it from source. I ran make and make install which hindsight may have been the wrong decision.
Now I do not seem to have any internet connectivity. Does anyone know what I may have over written to cause this or at least where specifically I can look to track this issue down?
Note: I can Putty into the Linux machine but it doesn't seem to have any other connectivity, specifically HTTPS
It's a bit weird that this would break network connectivity. One possible explanation is that the system has networking scripts or a network manager that relies on Python, and it got broken after make install replaced your default Python installation. It may be possible to fix this by reinstalling your RHEL Python packages (sorry, cannot offer more detailed help there, as I don't have access to a RHEL box).
I guess the lesson is "be careful about running make install as superuser". To easily install and manage different Python versions (separate from the system Python), the Anaconda Python distribution would be a good solution.
I suggest to undo that 3.6 installation and use the Software Collections version of python 3.6. See here for python 3.6 installation. Software Collections install "along side" the original versions so as to not affect the OS - and they are included in the subscription.
So after a lot of time slamming my head against the wall I got it worked out. My best guess is that the system (RHEL 7) relied on something from its default Python2.7 installation to handle SSL negotiations. Installing 3.6 alongside must have overwritten some pointer. Had I done this correctly, with altinstall all would have likely been fine.
The most frustrating part of this is that there were no error messages, connections just timed out.
To fix this, I had to uninstall all Python versions and then reinstalled Python2.7 - Once Python2 was back in the system it all seemed to work well.
In Debian Jessie/8 there is GCC 4.9.2.
I need the latest version, GCC 6.x.
Is it possible to install it through Synaptic from the testing repository (i.e. the binary, not the source), in parallel with the old version?
Is there a risk of conflicts among libraries/headers/... Are they going to be stored in separate directories like gcc-4.9/ gcc-6.0/ ...?
So far, I have only been able to install a second compiler building it from source, in its own directory.
Yes sure.
If two packages conflict (e.g. because they contain the same file), then he package manager (apt, aptitude, synaptics, ...) will refuse to install both at the same time.
So you can install any packages in parallel, as long as the package manager allows you to.
E.g. on my system, I have installed both gcc-5 and gcc-6.
Technically, the Conflict is expressed explicitely by the maintainer of a package.
Obviously they cannot track all possible packages in the world, but instead really concentrate on the target release (e.g. packages from jessie properly conflict with other packages from jessie, but not necessarily with packages from woody (aka Debian GNU/Linux 3.0)).
Since upgrading between consecutive releases (e.g. jessie -> stretch) is considered crucial, you can also rely on proper Conflicts when installing testing (aka next-to-be-stable) packages on stable systems.
OTOH, there might of course be bugs in the packaging, where the Conflicts are not properly expressed (if you find one, don't hesitate to report it).
If this happens to happen, the installation will fail, and you can revert the change.
So it's pretty safe to try to install whatever packages are available in Debian.
(However, I wouldn't put that much trust into 3rd party repositories)
To the kind people of SO,
I am having trouble finding any resources for installing NodeJS (current or earlier version) onto a RHEL4 box. I am starting to doubt if this is even possible as the OS dates back 10 years now. The machine has Python 2.3.4 and GCC 3.4.6, if that's of any help.
I am hoping someone here could maybe point me in the right direction, I feel I may be grasping for straws at this point.
There is only a handful of possibility, since from comment, you said upgrading the box is not a option. (I d like you to know there is security implications too, you should have a up-to-date OS):
Install the official way, which need yum and sudo rights.
Compile from source, which in theory doesn't need sudo rights nor yum.
Note that, even if compiling from source should be easy:
wget https://nodejs.org/dist/latest-v4.x/node-v4.4.7-linux-x86.tar.gz
tar -xzf node-v4.4.7-linux-x86.tar.gz
cd ./node-v4.4.7-linux-x86
./configure #Options
make
make install
You will almost always run into issues because of not installed or outdated dependencies. At this step, you may want to track down a previously supported version of node.js for RHEL4 (0.10.x?), or try to make a case about upgrading the box.
I have Linux Mint in my home computer and I'm about to install Debian Jessie in my work computer. I have dealt with Debian before and many packages that are available in Ubuntu repositories by default aren't available for Debian. As someone who needs all those packages I was wondering what would be the correct way of installing them on Debian.
The first thought that came to me was adding Ubuntu sources to sources.list, but I read some things and apparently people do not recommend this.
Since I have to install many of these packages, I also would like to avoid having to install them from source one-by-one.
What would be the preferred way to do this task?
Thank you.
I'm don't think you can install them from the repos if you don't want to add sources in sources.list.
If we are talking about reasonably small number of packages (say 10) I would recommend checking if .deb packages exist on the home pages.
For example:
http://pkgs.org/download/ipython
This is much easier than installing from source. It's not fully automated solution, but for smaller number of packages you can do it.
I hope it helps.
I have never used Linux OS. Want to know how we can start compiling Apache,Mysql and php in Linux and is it necessary to configure it.
I tried doing it by using cd/user/scr/httpd_2.0.09
Do we need to downloads the set up from google
Do yourself a favour and don't try to compile your own webserver etc. ;)
Aside from the fact that it's a lot of work to set up the tools for compiling, resolve dependencies, and debug possible errors, you will have to do the same procedure with every tiny update – instead of simply getting a new version via your package manager.
If you use a common distribution, install the packages required for the so-called LAMP stack, and configure them properly. That will be hard enough for starters.
If you're using Ubuntu, have a look here: https://help.ubuntu.com/community/ApacheMySQLPHP
Actually installing binaries from repositories is less painful than compiling, but if you really want so, you may install Gentoo or other source-based distributive. I've simply described compilation of MySQL 5.5 in my blog.
To compile packages on Debian based systems you need to install build-essential and cmake package (and maybe some other *-dev packages, which appears to be missing during source configure).
For example to compile MySQL 5.5 it is enough to run:
cmake . #yep, with dot. Will prepare your source according to your system
make
make install #will install compiled binaries to system