Fedora 17 in a CHROOT on Ubuntu - and the wrong dependency on rpmlib(X-CheckUnifiedSystemdir)

[Bill Davidsen]

Suvayu Ali wrote:
> Hi Bill,
>
> On Fri, Sep 14, 2012 at 10:31:20AM -0400, Bill Davidsen wrote:
>> Marc Wäckerlin wrote:
>>> Hi
>>>
>>> I am working in Ubuntu and compiling RPMs for Fedora. That's why I install Fedora in
>>> a **chroot** environment. That works fine with Fedora 16, but fails with Fedora 17 due
>>> to the wrong "rpmlib(X-CheckUnifiedSystemdir)" dependency.
>>>
>>> I Do not upgrade and I cannot use dracut, because Fedora 17 is in a chroot and cannot
>>> boot. So the instructions at http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum
>>> do **not** help.
>>>
>>> How to solve the problem? What does dracut do, why(*) does rpm fail, where does this
>>> dependency come from? How can I either fake this dependency or prevent RPM from requiring
>>> it? I need a deep inside knowledge on what's going on, what dracut does and what rpm does.
>>> What have the fedora-guys patched to get thie wrong dependency, and how can I undo it?
>>>
>>> ----
>>> (*) I mean technically *why*, not user-view answers like "to prevent upgrades without
>>> fs-migration", this kind of answer does not help, but technical answers like "dracut
>>> creates content X in file Y, then the dependency is ignored in rpm"
>>>
>> Marc, I have to ask why you are doing that as opposed to just creating a VM
>> and running Fedora in that. It just seems so much easier. And I have friends
>> running fc17 in VM on both Mac and Windows7, so it's pretty sure Ubuntu
>> would do so as well.
>>
>> Just curious why you took that approach.
>>
>
> I have a similar build system for SLC 5.7.  Our software can also be
> deployed in a VM; I have tried that but found the overhead of using a VM
> (build times, test job run times and the fact that you have to have a
> working virtualisation setup) rather large.  Instead now I (and many of
> my colleagues) use a few scripts to maintain the chroot system for our
> software.  This also seems easier to implement across multiple linux
> distros without much fiddling (it's after all a few scripts that uses
> chroot to setup the environment).  To give you an idea about the "easy
> on various" distros bit, we have tried this on Arch, Ubuntu, Fedora and
> Debian.  Getting it to work on Fedora required some extra effort to get
> the SELinux labels for the chroot'ed directory hierarchy correct.
>
Your last sentence sums up some of the issues I hit with chroot, but I'm glad it 
works well enough for your needs. I don't like to worry about the build options 
of the kernel I run vs. the environment of another distribution, so I went the 
VM route using a raw disk image. It runs on either of my home hosting machines, 
or my laptop in a pinch, and at least the MINT VM I built for testing reportedly 
runs under Mac VM, whatever comes with Windows7, and VMware (I think on VISTA).

Whatever works for you, either way will work, but I don't want to ever find out 
that an update to SElinux changed behavior, or glibc was patched to a "more 
correct" but non-working state. The right solution is the one which uses the 
least of your time in this case.

-- 
Bill Davidsen <davidsen at tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot