This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
Subject: Re: rpm -qa | xargs rpmfind --auto --latest From: Hugo Rabson <hugo.rabson@zetnet.co.uk> Date: Wed, 07 Apr 1999 13:10:11 -0000 () On 07-Apr-99 felix k sheng <felix@deasil.com> wrote: > On Tue, Apr 06, 1999 at 12:38:46PM +0100, Hugo Rabson wrote: >>Just a thought... I've never tried it... > Wouldn't you need to make that: > # rpm -qa | perl -pe 's/-[^-]+-[^-]+$/\n/' | xargs rpmfind --... > so that you strip off the version and the release? Good point. :) Tell you what... How about this...... <<<----------------------------------->>> #!/bin/sh if [ "$#" -ne "1" ] ; then echo "update-old-rpms <days_old>" exit 2 fi too_old=$(($1*60*60*24)) right_now=`date +%s` for fname in `rpm -qa | perl -pe 's/-[^-]+-[^-]+$/\n/'` ; do datestr=`rpm -q $fname -i |grep "Install date" | head -n 1 | \ gawk '{ print $5,$4,$7;}'` installtime=`date +%s -d "$datestr"` age=$(($right_now-$installtime)) if [ "$installtime" != "" ] && [ "$age" -ge "$too_old" ] ; then echo $fname fi done exit 0 <<<----------------------------------->>> Save it as update-old-rpms; chmod +x; it'll tell you how many RPMs are more than N days old. To upgrade them all (not for the foolhardy!), this might do the job...? for i in `./update-old-rpms` ; do rpmfind $i done :) I love how easy it is to customize Linux. Try doing anything like this to get NT4's hotfixes... === Subject: Re: rpm -qa | xargs rpmfind --auto --latest From: James Michael Keller <jmkeller@radix.net> Date: Wed, 07 Apr 1999 20:36:10 -0400 Hugo Rabson wrote: > > On 07-Apr-99 felix k sheng <felix@deasil.com> wrote: > > On Tue, Apr 06, 1999 at 12:38:46PM +0100, Hugo Rabson wrote: > >>Just a thought... I've never tried it... > > Wouldn't you need to make that: > > # rpm -qa | perl -pe 's/-[^-]+-[^-]+$/\n/' | xargs rpmfind --... > > so that you strip off the version and the release? > > Good point. :) > > Tell you what... How about this...... > > <<<----------------------------------->>> > #!/bin/sh > > if [ "$#" -ne "1" ] ; then > echo "update-old-rpms <days_old>" > exit 2 > fi > too_old=$(($1*60*60*24)) > right_now=`date +%s` > for fname in `rpm -qa | perl -pe 's/-[^-]+-[^-]+$/\n/'` ; do > datestr=`rpm -q $fname -i |grep "Install date" | head -n 1 | \ > gawk '{ print $5,$4,$7;}'` > installtime=`date +%s -d "$datestr"` > age=$(($right_now-$installtime)) > if [ "$installtime" != "" ] && [ "$age" -ge "$too_old" ] ; then > echo $fname > fi > done > exit 0 > <<<----------------------------------->>> > > Save it as update-old-rpms; chmod +x; it'll tell you how many RPMs are > more than N days old. > > To upgrade them all (not for the foolhardy!), this might do the job...? > > for i in `./update-old-rpms` ; do > rpmfind $i > done > > :) > I love how easy it is to customize Linux. Try doing anything like this to > get NT4's hotfixes... Then change to rpmfind --latest --sources <package> Then build a list of the updated packages, let rpmfind get the source rpms, then call for each package in the queue rpm --rebuild <package>*.src.rpm then rpm -Uvh the new binaries :) Or if you want to forgo compiling local binary rpms (I always try to compile my own binaries -- avoids silly library conflicts) Pick up autorpm, mirror your favorite rpm ftp site locally each night (only a few packages will change) and then let it update from the local rpm mirror. I do this with the updates dir only, so I'm at most 23 hours behind any security patches. === Subject: Re: RPM HOW-TO From: Jan Carlson <janc@iname.com> Date: Thu, 08 Jul 1999 21:48:23 -0400 Rick Forrester wrote: > > krisj@ibm.net said: > > I was wondering if there is a newer RPM building how-to than the one > > on LDP: http://metalab.unc.edu/mdw/HOWTO/RPM-HOWTO.html? Is there > > others that anyone else has used and had good success with? I just > > want to make sure the when I build RPMS, that I'm doing it the right > > way. This document that I found is dated April 1997. Kind of a log > > time for linux I would think. And I'm sure a lot of things has changed > > with RPM since then. > > > Kris Jordan > > per Ed Bailey, a new copy of "Maximum RPM" is in the works right now; > an upgraded RPM-HOWTO should be forthcoming, also. And an official new rpm is out. rpm-3.0.2-6.0.i386.rpm for RH6, and also an rpm-3.0.2-X for every other Red Hat version too. There is a discussion of new rpm-3.0.2 features for rpm builders in www.redhat.com/errata. === Subject: Re: tetex screwed up after an upgrade From: "Steve \"Stevers!\" Coile" <scoile@redhat.com> Date: Wed, 9 Jun 1999 13:48:29 -0400 (EDT) On Wed, 9 Jun 1999, Kayvan Aghaiepour Sylvan wrote: [...] > Thomas> Steve, does this mean RPM does not report files properly, or > Thomas> that on an upgrade from 5.2 to 6.0 it does not install all > Thomas> files in the packages properly? I am confused and now leery > Thomas> of upgrading my 5.2 system to 6.0, especially since tetex is > Thomas> pretty important to me. The problem is that RPM is not properly tracking files that are shared between different packages. For instance, if /opt/foo is owned (shared) by packages "bar" and "baz", and you remove package "bar", /opt/foo will be removed, even though package "baz" still owns it. === Subject: Re: RPM problem? From: Jan Carlson <janc@iname.com> Date: Mon, 05 Jul 1999 16:46:57 -0400 Joe Brenner wrote: > > "Patrick O. Neil" <patrick@hci.utah.edu> wrote: > > > I end up having to > > explicitly kill the PID for rpm in that instance so I can go > > on to install other packages. If I don't, I am unable to get > > past the lock file that the first rpm produces. > > > Even though I kill the rpm PID at this point, I find that the > > rpm IS installed - I can start kde up without any problems. > > This is one of my complaints about RPM: if the installation > process is interrupted in the middle (e.g. on something as > simple as a disk-full problem), you can get most of the files > installed on your machine, but the RPM database doesn't get > updated at all. You can't then use rpm to remove the files: > you've got to manually delete them. > > Or I don't know, maybe I could force an update of the rpm > database and that would work... but still this kind of thing > is a serious annoyance considering this is a tool thats > supposed to make these things easier. First free up some disk space. Next install the rpm that was half installed before. Then remove it. Now all the files from the rpm are gone. === From: Rick Forrester <rickf@crow.jpl.nasa.gov> Subject: Re: Installation of a RPM package Date: Wed, 07 Jul 1999 08:29:35 -0700 wellingtonuemura@hotmail.com said: > One question by me now,how do i install these RPMS located in RedHat > CD 2?They dont install,Why? Wellington, the RPM's on the second CD are the source rpms; they can be used to allow you to rebuild the RPM's, examine the code & any patches that have been made, etc. When you install a source RPM (foo-2.13.4-3.src.rpm, for example), you should cd to /usr/src/redhat. In that directory, you'll find the following subdirs: BUILD RPMS SOURCES SPECS SRPMS After installing foo-2.13.4-3.src.rpm, you should find a spec file, foo.spec, in SPECS. You should find a source tarball, such as foo-2.13.4.tar.gz in SOURCES. If you want to rebuild an RPM on your system, you can just cd into the SPECS subdirectory and issue the command "rpm -ba foo.spec", or one of the variants thereof. After this, you'll find a new source rpm in SRPMS, the build tree (uncompressed tarball) in BUILD, and the new binary RPMs under RPMS - in an appropriate subdir, such as RPMS/i386, RPMS/i586, RPMS/alpha, etc. If you have a new version of a software package, and that s/w package doesn't require patching to build on your system, you can make an RPM of it as simply as this: 1. Find an RPM of a prior version. 2. Install the RPM of the prior version. 3. Replace the tarball in SOURCES with the new one. 4. Edit the spec file in SPECS as appropriate. Watch the version and release information, and clear out any old patches or other rubbish. 5. rpm -ba <specname.spec> 6. test the new RPM on your system, make available as appropriate. Last point: a good reason to get the source RPM rather than the binary is when you're downloading from a location you may not have full confidence in. Install the source RPM and examine the spec file to see what scripts, etc., are included and executed during binary installation. Then untar the tarball in BUILD and inspect the contents. If all appears as it should be, then do a build of the RPM and install it. === Subject: Re: Installation of a RPM package From: Kurt Wall <kwall@xmission.com> Date: Wed, 7 Jul 1999 09:39:56 -0600 Also sprach Tony Devalli