[lug] rpm and temp files

[D. Stimits]

John Karns wrote:
> 
> On Tue, 12 Dec 2000, John Hernandez uttered:
> 
> > "D. Stimits" wrote:
> 
> > > Until I find a cure, this is what I've actually done. RPM's have a
> > > tendency to understand RH's current install config though, so they are
> > > useful even if tarballs work too. I find it preferable not to bypass rpm
> > > if it is possible.
> > >
> >
> > I agree in the case where it's possible AND practical.  I probably
> > should gain a better understanding of RPM.  That is, unless someone out
> > there can convince me to switch to a better system...Debian users?  I
> > think I'm reviving a burried topic, but what's better than RPM?  Does
> > dpkg exhibit frustrating problems like these?  Other RPM substitutes?
> 
> In many cases I have used mc (midnight commander) to "open" the rpm
> containing binaries and copied the binaries into the destination
> directory.  mc handles rpm's like it does tar and tar.gz files making it
> easy to do.  The disadvantage is that your rpm database won't get updated
> nor will any scripts run.  Also, for very large rpm files on the order of
> 30Mb or greater, it can be prohibitively slow.
> 

What makes this seem particularly broken for an rpm is that the ones in
question are source rpms. In the most recent case it was a matter of
hanging when it tried to rm a file that it had decided not to create in
the first place (it detected the system already had the command, so it
didn't generate it; but then it died off because it didn't also
compensate).

In many other rpm's from RH 7, that are source, it is demanding glibc be
more current than the latest from RH 6.2, which is wrong. The minor
version difference is only relevant for these other packages if
distributed in binary format; it makes me feel like RH is trying to get
people to upgrade to 7 by providing source packages that break on 6.2
(but would work fine with --rebuild if they were spec'd right; my rpm
program itself is 3.05, and handles the new formats...the source
packages are what remain broken).

D. Stimits, stimits at idcomm.com