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@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@xxxxxxxxxxxxx
> http://lists.rpm.org/mailman/listinfo/rpm-list
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxxxxx
http://lists.rpm.org/mailman/listinfo/rpm-list
