How to implement and check a rpm for an 'rpmlib' capability

Thierry Parmentelat thierry.parmentelat at inria.fr
Tue Mar 10 13:21:43 UTC 2015


As a follow-up on this, I guess I can exhibit an even simpler use case where this issue triggers, if I simply run the following command inside a fedora21 box

fedora21host ~ # yum -y --releasever=18 --nogpg --installroot=/containers/fedora18guest --disablerepo='*' --enablerepo=fedora install systemd passwd yum fedora-release vim-minimal
Failed to set locale, defaulting to C
fedora/18/x86_64/metalink                                                                                                                                                                              | 5.5 kB  00:00:00
fedora                                                                                                                                                                                                 | 4.2 kB  00:00:00
(1/2): fedora/18/x86_64/group_gz                                                                                                                                                                       | 368 kB  00:00:00
(2/2): fedora/18/x86_64/primary_db                                                                                                                                                                     |  17 MB  00:00:04
Resolving Dependencies
--> Running transaction check
---> Package fedora-release.noarch 0:18-1 will be installed
---> Package passwd.x86_64 0:0.78.99-3.fc18 will be installed
--> Processing Dependency: pam >= 1.0.90 for package: passwd-0.78.99-3.fc18.x86_64
--> Processing Dependency: libselinux >= 2.1.6-3 for package: passwd-0.78.99-3.fc18.x86_64

<snip>

(117/120): xz-libs-5.1.2-2alpha.fc18.x86_64.rpm                                                                                                                                                        | 100 kB  00:00:00
(118/120): yum-3.4.3-47.fc18.noarch.rpm                                                                                                                                                                | 1.1 MB  00:00:00
(119/120): yum-metadata-parser-1.1.4-7.fc18.x86_64.rpm                                                                                                                                                 |  27 kB  00:00:00
(120/120): zlib-1.2.7-9.fc18.x86_64.rpm                                                                                                                                                                |  88 kB  00:00:00
------------------------------------------
Total                                                                                                                                                                  2.2 MB/s |  59 MB  00:00:27
Running transaction check
ERROR You need to update rpm to handle:
rpmlib(X-CheckUnifiedSystemdir) is needed by setup-2.8.57-1.fc18.noarch
rpmlib(X-CheckUnifiedSystemdir) is needed by filesystem-3.1-2.fc18.x86_64
RPM needs to be updated
 You could try running: rpm -Va --nofiles --nodigest
Your transaction was saved, rerun it with:
 yum load-transaction /tmp/yum_save_tx.2015-03-10.14-16.dO2X75.yumtx


I really could use some feedback on this :-)

thanks — Thierry


> On 02 Mar 2015, at 12:02, Thierry Parmentelat <thierry.parmentelat at inria.fr> wrote:
> 
> Hi there
> 
> 
> I have a post in relation with a - much older - thread - back in Feb. 2013; I’m using the same Subject: just in case 
> 
> 
> ** the background
> 
> We have a build setup, where we build fedora instances as guests in a fedora host (guests are lxc containers, but that does not matter for the issue)
> 
> In the process of bootstrapping the guest, we invoke the host rpm/yum binaries to create a first viable image, that can then be chroot’ed into for further populating the guest image
> 
> 
> ** the older thread
> 
> 2 years ago, I filed an issue we had when trying to build a f18 guest inside a f14 host
> 
> the issue was that the host(f14) rpm did not expose the special 'X-CheckUnifiedSystemdir’ capability that the filesystem rpm from f18 depends on
> 
> 
> 
> ** the new issue
> 
> meanwhile we have moved the host to f18 and then f20, and the issue had of course vanished
> 
> except that now that I have a host based on fedora21, the issue is back; as much as the fedora14 rpm binary did *not yet* expose this capability, it seems that the fedora21 rpm binary does not expose it *any longer*
> 
> 
> is this a fair way to describe the situation ?
> if yes, would it be possible to have the mainstream rpm expose this capability again ?
> otherwise what would be the recommended way to work around this problem ?
> 
> thanks in advance for any insight on this — Thierry
> 
> 
> 
>> On 02 Feb 2013, at 13:16, Thierry Parmentelat <thierry.parmentelat at inria.fr> wrote:
>> 
>> Many thanks for the feedback
>> 
>> I've actually found my way out by essentally rebuilding f18's rpm more or less as is (just turning off selinux for unresolved symbols) 
>> 
>> Which is something that I had tried at the time when I wrote this, but as a matter of fact my real problem was, due to some obscure hacks that I was not aware of, rpm was indeed invoked on an image where a /sbin/ was present, 
>> And so the code that runs before actually providing 'rpmlib(X-CheckUnifiedSystemdir)' was silently exiting, hence my symptoms below
>> Having removed these dirty patches now works like a charm
>> 
>> Thanks again for the feedback, and sorry for not reporting that earlier but I was starting to think I wouldn't get anything by this channel :-)
>> 
>> Talking of which, I have another- completely unrelated -  trouble with this scenario, so I'll describe it in another post
>> 
>> -- Thierry
>> 
>> On Feb 2, 2013, at 12:14 PM, Panu Matilainen wrote:
>> 
>>> On 01/29/2013 04:04 PM, Thierry Parmentelat wrote:
>>>> Hi
>>>> 
>>>> I'm facing issues with rpm in a rather convoluted scenario, where a fedora14 physical box spins off virtual machines, and in the mix invokes rpm/yum to build guest images
>>>> 
>>>> Long story short, for guests under fedora 17 and 18, I run into this
>>>> ERROR You need to update rpm to handle:
>>>> rpmlib(X-CheckUnifiedSystemdir) is needed by filesystem-3.1-2.fc18.x86_64
>>>> rpmlib(X-CheckUnifiedSystemdir) is needed by setup-2.8.57-1.fc18.noarch
>>>> 
>>>> As far as I understand fedora has added this as a precaution for upgrades across the f16/f17 barrier and I really do not plan on doing any of this, so using an rpm binary/package that fakes this 'X-CheckUnifiedSystemdir' thing would be enough for my needs at first sight
>>>> 
>>>> Trying to work around that, I made an attempt to rebuild f18's rpm under f14; which was easy enough; at first sight it seemed to have the proper f18 patch so I was optimistic :)
>>>> 
>>>> -----
>>>> Unfortunately using this new rpm did not solve the issue, and when trying to check that the new rpm indeed had the required capability - or whatever the proper name is here, I mean 'X-CheckUnifiedSystemdir' - I realized that even with the native f18 rpm I was not able to spot that feature:
>>>> 
>>>> # rpm -qp rpm-4.10.2-1.fc18.x86_64.rpm --provides
>>>> warning: rpm-4.10.2-1.fc18.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID de7f38bd: NOKEY
>>>> config(rpm) = 4.10.2-1.fc18
>>>> rpm = 4.10.2-1.fc18
>>>> rpm(x86-64) = 4.10.2-1.fc18
>>>> 
>>>> 
>>>> mmh, my first thought had been this would show up in there, but obviously, it's not, even with the stock f18 rpm
>>>> so digging further I found references here and there to --showrc; I',m not sure that I captured that one, but here's what I get
>>>> 
>>>> root at mirror /mirror/fedora/updates/18/x86_64 # rpm -qp rpm-4.10.2-1.fc18.x86_64.rpm --showrc | grep rpmlib
>>>> Features supported by rpmlib:
>>>>  rpmlib(BuiltinLuaScripts) = 4.2.2-1
>>>>  rpmlib(CompressedFileNames) = 3.0.4-1
>>>>  rpmlib(ConcurrentAccess) = 4.1-1
>>>>  rpmlib(ExplicitPackageProvide) = 4.0-1
>>>>  rpmlib(FileCaps) = 4.6.1-1
>>>>  rpmlib(FileDigests) = 4.6.0-1
>>>>  rpmlib(HeaderLoadSortsTags) = 4.0.1-1
>>>>  rpmlib(PartialHardlinkSets) = 4.0.4-1
>>>>  rpmlib(PayloadFilesHavePrefix) = 4.0-1
>>>>  rpmlib(PayloadIsBzip2) = 3.0.5-1
>>>>  rpmlib(PayloadIsLzma) = 4.4.2-1
>>>>  rpmlib(PayloadIsXz) = 5.2-1
>>>>  rpmlib(ScriptletInterpreterArgs) = 4.0.3-1
>>>>  rpmlib(VersionedDependencies) = 3.0.3-1
>>>> 
>>>> which already looks better indeed; except that it does not mention X-CheckUnifiedSystemdir...
>>> 
>>> The query above doesn't do what you probably think it does:
>>> rpmlib() dependencies are provided by the running rpm instance, and cannot be provided by packages. So the "-qp rpm-4.10.2-1.fc18.x86_64.rpm" part doesn't make sense there - it will output the what "rpm -qp rpm-4.10.2-1.fc18.x86_64.rpm" would output, AND then --showrc additionally outputs the rpmlib() provides of the running rpm which in case of F14 is rpm-4.8.x IIRC.
>>> 
>>> You'd need to upgrade the host rpm to that of F18 (or F17) to have it provide the X-CheckUnifiedSystemdir magic. And even there it actually doesn't show up in --showrc because its, uh, rather special.
>>> 
>>>> 
>>>> ---
>>>> I am quite obviously missing the point here
>>>> All I would like to achieve is to build an rpm that pretends to have the required feature - without any actual change, can anybody shed some light on how to do that ?
>>> 
>>> For your purposes it sounds like faking the thing should indeed be sufficient. Something like this should do the trick:
>>> 
>>> --- a/lib/rpmds.c
>>> +++ b/lib/rpmds.c
>>> @@ -962,6 +962,9 @@ static const struct rpmlibProvides_s rpmlibProvides[] = {
>>>      (                RPMSENSE_EQUAL),
>>>   N_("support for POSIX.1e file capabilities") },
>>> #endif
>>> +    { "rpmlib(X-CheckUnifiedSystemdir)", "1",
>>> +       (                RPMSENSE_EQUAL),
>>> +    N_("fake X-CheckUnifiedSystemdir provide") },
>>>   { NULL,                            NULL, 0,        NULL }
>>> };
>>> 
>>> 
>>> ...but note that this needs to be applied to the host rpm building the vm images. Ie apply the above to F14 src.rpm, rebuild and install on the F14 host.
>>> 
>>> 	- Panu -
>>> 
>>> _______________________________________________
>>> Rpm-list mailing list
>>> Rpm-list at lists.rpm.org
>>> http://lists.rpm.org/mailman/listinfo/rpm-list
>> 
> 



More information about the Rpm-list mailing list