New answers tagged

0

This is an old question that may need a fresh answer. Learn about spacecmd -- it'll save your brain and mouse-clickety hand some needless pain. AND, it can be scripted, even if it's a bit wordy. for CHNL in `spacecmd -q -- softwarechannel_list`; do spacecmd -q -- \ softwarechannel_listchildchannels ${CHNL} \ | xargs -n1 \ spacecmd -q -y -- \ ...


1

In this case, I would actually choose a third way: Create a lib/ directory somewhere, put the symlink there, and export LD_LIBRARY_PATH pointing to the created directory (preferably modify the start script of the program, or create one if it doesn't exist). This way, when the program starts, it will look for shared libraries there first, and will find ...


0

I would recommend installing the libpng-devel package. you also need the header files! if you install the library using an rpm; then why not install the .so using an rpm; better keep both up to date with each other.


0

you can do this using following process: use rpm -ivh --nodeps <packagename> for i386 first and then for X86_64.


1

Basically, the answer is no. You should be able to keep track of the backported features using the package log/revision, but nothing more.


2

# rpm -K rpm-2.3-1.i386.rpm rpm-2.3-1.i386.rpm: size pgp md5 OK From http://www.rpm.org/max-rpm/s1-rpm-checksig-using-rpm-k.html


6

This turns out to be quite a difficult problem, if you limit yourself to the single system which you're trying to validate. Fortunately, we live in the real world, where there is more than one computer! Some possibilities for verifying the binary include: Using another reference system which has the same package version of RPM installed, take a hash of ...


1

When you install from a tarball, many times the binary is installed in /usr/local. Probably your new openssl binary can be found in /usr/local/bin. Yet it would be easier to just install an rpm. You installed a source rpm, which contains the sources but not the binaries. You need to look for openssl.x.y.z.rpm (and not openssl.x.y.z.src.rpm).


0

For what it is worth, it generally is a bad practice to compile custom packages on enterprise-level distribution. Most of the time, you should stick with the default distro packages, or only use trusted repositories. The problem with compiling custom packages, and to directly use RPMs, is that each update is much more labor intensive and error prone than a ...


0

The 'user' warnings are not an issue. Please do 'rpm -qil openssl' and 'which openssl' I suspect you have multiple openssl versions installed. 'which openssl' will tell you which one your shell is using, and rpm will show you where the RPM version is installed. You will probably want to remove all but the RPM installation, but since I don't know the ...



Top 50 recent answers are included