I am using redhat 7.3 and I am trying to install openssl-devel-0.9.6b-18.i386.rpm but I get the following error message when I try to install:
error: failed dependencies:
openssl = 0.9.6b-18 is needed by openssl-devel-0.9.6b-18
The thing that confuses me most is that when I check my machine it says that openssl-0.9.6m-2.src.rpm is already installed. I notice that this is a different version than the one openssl-devel requires, but the build date of
"openssl-0.9.6m-2.src.rpm" is Tue Jun 1 14:01:14 2004 and is actually newer than the build date of "openssl-0.9.6b-35.7.i386.rpm" which is 2003/Sep/24 21:24:27 .
I hessitate to install the older version, "openssl-0.9.6b-35.7.i386.rpm" on top of my existing newer version, "openssl-0.9.6m-2.src.rpm".
Is this anything to be worried about? I'm just worried that if I install the older version on top of the newer version it'll overwrite some files and something will stop working on my machine, because I don't know what other dependencies are depending on my existing version on my machine at the moment.
Hi,
I want to install 'Devel-Profile' in windows but i am not able to install.
Here is the error.
PPM> install Devel-Profile
Install package 'Devel-Profile?' (y/N): y
Installing package 'Devel-Profile'...
Error installing package 'Devel-Profile': Could not locate a PPD file for... (3 Replies)
Hi
I want to install glib-devel-2.xx on suse 9 linux.
I downloaded from below site,
Index of /pub/gnome/sources/glib/2.24
and installed using normal configure,make,make install.
Am I correct or something else is required?
Thanks. (4 Replies)
Dear All...
I'm trying to install openssl (openssl-0.9.7m) on a Solaris box running 5.9...
I'm using the following command...
./Configure --openssldir=/data/ssl solaris-sparcv9-gcc
However when I do make I get the following...
root@adc8-winn:/usr/local/openssl-0.9.7m 0 # make... (1 Reply)
I am trying to install Postfix on a Sun SPARC Solaris 9 server. I am not sure whether it is essential or not but still installed MySQL on that server and it is running fine.Now when I am trying to run the make command as a part of installation of Postfix, it reports the following error.
# make ... (1 Reply)
I have a question on how to make an rpm out of the source package distribution. just looking for a general procedure. Like say I have the MIT kerberos source, would I "make -C libs" or something like that? (2 Replies)
Carton::Doc::FAQ(3pm) User Contributed Perl Documentation Carton::Doc::FAQ(3pm)NAME
Carton::Doc::FAQ - Frequently Asked Questions
QUESTIONS
It looks useful, but what is the use case of this tool?
The particular problem that carton is trying to address is this:
You develop a Perl web application with dozens of CPAN module dependencies. You install these modules on your development machine, and
describe these dependencies in your Makefile.PL or some other text format.
Now you get a produciton environment on Cloud PaaS provider or some VPS, you install the dependencies using "cpanm --installdeps ." and it
will pull all the latest releases from CPAN as of today and everything just works.
A few weeks later, your application becomes more popular, and you think you need another machine to serve more requests. You set up another
machine with vanilla perl installation and install the dependencies the same way. That will pull the latest releases from CPAN on that
date, rather than the same as what you have today.
And that is the problem. It's not likely that everything just breaks one day, but there's always a chance that one of the dependencies
breaks an API compatibility, or just uploaded a buggy version to CPAN on that particular day.
Carton allows you to lock these dependencies into a version controlled system, so that every time you deploy from a checkout, it is
guaranteed that all the same versions are installed into the local environment.
How is this different from DPAN or CPAN::Mini::Inject?
First of all, if you currently use DPAN, CPAN::Mini::Inject, Shipwright or any other similar tools successfully, then that's totally fine.
You don't need to switch to carton.
If you experience difficulties with these tools, or are interested in what could be better in carton, keep on reading.
carton definitely shares the goal with these private CPAN repository management tool:
o Manage the dependencies tree locally
o Take snapshots/lock the versions
o Inject private modules into the repository
Existing tools are designed to work with existing CPAN clients such as CPAN or CPANPLUS, and have accomplished that by working around the
CPAN mirror structure.
carton internally does the same thing, but its user interface is centerd around the installer, by implementing a wrapper for cpanm, so you
can use the same commands in the development mode and deployment mode.
Carton automatically maintains the carton.lock file, which is meant to be version controlled, inside your application directory. You don't
need a separate database or a directory to maintain tarballs outside your application. The carton.lock file can always be generated out of
the local library path, and carton can reproduce the tree using the lock file on other machines.
I'm already using perlbrew and local::lib. Can I use carton with this?
If you're using local::lib already with perlbrew perl, possibly with the new "perlbrew lib" command, that's great! There are multiple
benefits over using perlbrew and local::lib for development and use Carton for deployment.
The best practice and workflow to get your perl environment as clean as possible with lots of modules installed for quick development would
be this:
o Install fresh perl using perlbrew. The version should be the same against the version you'll run on the production environment (if
any).
o Once the installation is done, use "perlbrew lib" command to create a new local lib environment (let's call it devel) and always use
the library as a default environment. Install as many modules as you would like into the devel library path.
This ensures to have a vanilla "perl" library path as clean as possible.
o When you build a new project that you want to manage dependencies via Carton, turn off the devel local::lib and create a new one, like
carton. Install Carton and all of its dependencies to the carton local::lib path. Then run "carton install" like you normally do.
Because devel and carton are isolated, the modules you installed into devel doesn't affect the process when carton builds the
dependency tree for your new project at all. This could often be critical when you have a conditional dependency in your tree, like
Any::Moose.
perl v5.14.2 2012-05-18 Carton::Doc::FAQ(3pm)