lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] debian chroot in redhat


From: Vadim Zeitlin
Subject: Re: [lmi] debian chroot in redhat
Date: Thu, 3 Oct 2019 17:59:37 +0200

On Thu, 3 Oct 2019 14:27:37 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2019-10-03 11:25, Vadim Zeitlin wrote:
GC> > On Thu, 3 Oct 2019 02:18:12 +0000 Greg Chicares <address@hidden> wrote:
[...]
GC> >  Are these warnings normal? I haven't seen either of them in my chroot.
GC> 
GC> AFAICT, the answers are as follows:
GC> 
GC> > GC> Warning: RPMDB altered outside of yum.
GC> 
GC> Yes, that's normal. We used the low-level 'rpm', going behind the
GC> back of the high-level 'yum'.

 I see, thanks.

GC> > GC> ** Found 30 pre-existing rpmdb problem(s), 'yum check' output follows:
GC> > GC> coreutils-8.22-24.el7.x86_64 has missing requires of ncurses
GC> 
GC> I'm afraid that might be a normal consequence, too.

 Sorry, but a consequence of what, exactly? I have trouble understanding
how installing a single RPM package manually (i.e. not using yum) could
have resulted in this, and I don't see what else did we do differently.

[...]
GC>   # yum reinstall crontabs initscripts pam pygpgme rpm rpm-python util-linux
GC> 
GC> and now we have a "solution", for the record:
GC> 
GC> [root@ugolyok]/tmp# yum check                                               
                
GC> Loaded plugins: fastestmirror, keys, protectbase
GC> check all
GC> [root@ugolyok]/tmp# echo $?
GC> 0

 I'm glad that the problem is solved, and I'm not sure if it's worth
investigating its origin if it's not going to happen again. But I still
don't really understand what exactly went wrong in the first place.

GC> > So the only firm conclusion I can make is that I don't really understand
GC> > how do package specifications work in RedHat world.
GC> 
GC> I begin to wonder whether {yum,rpm} are markedly inferior to {apt,dpkg}.

 They're definitely different, i.e. you can't just mechanically translate
dpkg invocations to rpm ones and apt ones to yum. But at the very least I
did find the solution to how to check for _all_ dependencies on a package
and not just dependencies on the package name (because apparently rpm has
the concept of depending on something provided by the package and not the
package itself): this can be done using a separate repoquery command

        # repoquery -q --installed --whatrequires nss-pem
        libcurl-0:7.29.0-54.el7.x86_64
        nss-0:3.36.0-7.el7_5.x86_64


GC> >  But, anyhow, the summary is that the required package should have been
GC> > installed as a dependency of curl and there is still the question about 
how
GC> > could you end up with curl but without nss-pem. However if your automated
GC> > chroot installation script contains "yum install -y curl", it should work.
GC> 
GC> I think 'curl' is not enough, and 'nss-pem' must also be installed.

 I just don't understand this :-( If you use "rpm -qi --requires" on curl,
you can see that it requires libcurl (doh). And if you run the same command
on libcurl, you can see that it requires "nss-pem(x86-64) >= 1.0.3-5", so
how is it possible that "yum install curl" doesn't install nss-pem? And, of
course, it did install it for me...

 If you're curious, could you please have a look at "yum history info NN"
output where "NN" is the ID of the corresponding command, as seen in "yum
history list" output? Maybe it will provide some explanation.

 Regards,
VZ

Attachment: pgpr36npEnn0O.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]