Tag Info

New answers tagged

0

You are not following the standard. /usr/local is designed to contain locally compiled files, i.e. files built in the local machine. When you create a package, the goal is to distribute it to other machines. Should you install your package on a machine then build the same software from source on the very same machine, the package files would be overwritten ...


0

Try running a yum update first. The ovirt-release.noarch.rpm did not include a RPM key and it's now complaining that there is no signing key available in your RPM configuration that can be used to verify the authenticity of the python-websockify-0.5.1-1.el6.noarch.rpm RPM. Poking around the ovirt website, I did find this page titled: oVirt Deployment ...


2

The fpm dev has this to say on the subject of distribution-specific guidelines: I want a simple way to create packages without all the bullshit. In my own infrastructure, I have no interest in Debian policy and RedHat packaging guidelines - I have interest in my group's own style culture and have a very strong interest in getting work done. (This is ...


2

If you want to take control of where various files will be installed you'll have to take responsibility for manually doing this within your RPM .spec file directly. Example Here's a snippet from a JBOSS RPM .spec file that I created in a blog series I wrote up a couple of years ago. The article in this series is titled: CentOS RPM Tutorial Part 3 - ...


2

rpmlint is a tool to check RPMs against some sort of packaging policy. Its configuration is typically distribution dependant and it checks packages against the particular distribution policy. Checking your own packages is fine as long as this is what you want. If your policy differs from the distribution policy, you either have to configure rpmlint ...


0

Try Removing the Conflicting Package by running yum remove perl-Compress-Raw-Zlib Run yum update This issue comes from RPM Forge Extra Repository with Version Mismatch.


4

You generally don't want to remove packages like this in pieces since there's typically dependencies that you're skipping over. Better to do this removal all at once like so: $ rpm -e $(rpm -aq | grep php) Better still I would encourage you to use yum to do this vs. RPM. $ yum remove $(rpm -aq | grep php) Even better then these would be to figure out a ...


1

( IFS=' ' ; printf 'rpm -e "%s"\n' $(rpm -qa |grep php) | . /dev/stdin ) There you go.


1

Try this script: for p in $(rpm -qa |grep php) ; do rpm -e ${p} ; done


4

Try this: rpm -qa | grep php | xargs rpm -e


1

It depends. If you are building for a specific distribution, depending on other rpms is ok. If building for different distributions, rather use library/file names, as the rpm-names where that lib is contained might differ.


0

At last, after almost six weeks of frustrated, numerous, attempted solutions based on suggestions by kind friends and Internet question sites, I have solved the problem (I think -- I am cautiously optimistic). The underlying symptom was that yum install emacs failed with a long list of errors,. Now it has finally worked, without hesitation. I don't know why, ...


0

They are in the spec file itself. See http://fedoraproject.org/wiki/How_to_create_an_RPM_package#Scriptlets In your case search for a %post section.


0

So this is how I get information in order to provide explicit dependencies for the spec file: Requires: see my script here; BuildRequires: use auti-buildrequires tool from Richard Jones;



Top 50 recent answers are included