yum exitcode changes in 3.2.19-3.fc9 break some mock builds

[Paul Howarth]

Seth Vidal wrote:
> On Fri, 2008-09-12 at 16:05 +0100, Paul Howarth wrote:
>> Today I tried building (in mock on a Fedora 9 host) some nmap packages 
>> for CentOS3 as version 4.76 came out. The mock build crashed out at the 
>> setup stage, due to the %pre script for the "dev" package failing (it 
>> thinks devfs is mounted). As I had built packages for version 4.75 only 
>> a couple of days ago, I tried rebuilding that and it now failed in the 
>> same way. I'd installed a bunch of updates in the last couple of days 
>> but the only one I could think of that might have caused that was the 
>> yum upgrade. So I downgraded yum from 3.2.19-3.fc9 to 3.2.17-2.fc9 and 
>> tried the build again, and this time it worked.
>>
>> The salient difference in the root.log was this:
>>
>>   DEBUG util.py:250:  Cannot install the dev package: mounted devfs 
>> detected.
>> +DEBUG util.py:250: 
>> --------------------------------------------------------------------------------
>> +DEBUG util.py:250:  Total                                           1.5 
>> GB/s |  14 MB     00:00
>>   DEBUG util.py:250:  error: %pre(dev-3.3.12.3-1.centos.0.x86_64) 
>> scriptlet failed, exit status 1
>>   DEBUG util.py:250:  error:   install: %pre scriptlet failed (2), 
>> skipping dev-3.3.12.3-1.centos.0
>>   DEBUG util.py:250:  ls:
>> @@ -233,8 +236,7 @@
>>   DEBUG util.py:250:  mkinitrd failed
>>   DEBUG util.py:250:  Installed: libpcap.x86_64 14:0.7.2-7.E3.5 
>> openssl-devel.x86_64 0:0.9.7a-33.24 pcre-devel.x86_64 0:3.9-10.4 
>> pkgconfig.x86_64 1:0.14.0-5 zlib-devel.x86_64 0:1.1.4-10.EL3
>>   DEBUG util.py:250:  Dependency Installed: dev.x86_64 
>> 0:3.3.12.3-1.centos.0 kernel.x86_64 0:2.4.21-57.EL krb5-devel.x86_64 
>> 0:1.2.7-68 losetup.x86_64 0:2.11y-31.24 lvm.x86_64 0:1.0.8-14 
>> mkinitrd.x86_64 0:3.5.13.6-1
>> -DEBUG util.py:311:  Child returncode was: 0
>> -DEBUG backend.py:436:  Copying packages to result dir
>> +DEBUG util.py:311:  Child returncode was: 1
>>   DEBUG backend.py:484:  umount -n /var/lib/mock/centos-3-x86_64/root/proc
>>   DEBUG util.py:272:  Executing command: umount -n 
>> /var/lib/mock/centos-3-x86_64/root/proc
>>   DEBUG util.py:311:  Child returncode was: 0
>>
>>
>> So the scriptlet failures that didn't formerly affect affect mock builds 
>> due to the zero exit code of yum are now causing build failures due to a 
>> "1" exit code.
>>
>> I'm not sure what the best approach to fixing this should be. It makes 
>> perfect sense to me for yum to return a non-zero exit code when there's 
>> a scriptlet failure yet in some cases this is a problem that doesn't 
>> affect the subsequent build.
>>
>> As I suspect that this is a problem that mainly affects legacy 
>> distribution versions, perhaps there could be a mock option that could 
>> be set in the config file to ignore the yum exit code?
>>
> 
> Yah - the exit code was changed with a scriptlet failure. I think the
> correct thing to do here is to fix the pkg causing the scriptlet
> failure.
> 
> Is there a reason why we can't do that?

This is without doubt the technically correct thing to do, though 
"official" updates for legacy distros and even RHEL 3 may be hard to get.

I've taken the approach of building workaround packages and adding them 
to a local repo in my buildsystem.

For CentOS 3, I needed a patched MAKEDEV package that didn't bail out of 
%pre (at least for the "dev" subpackage) if there was something mounted 
on /dev (which it assumed would be devfs).

For other distributions of similar vintage, I needed a hacked mkinitrd 
package with a patched new-kernel-pkg script that didn't return a "1" 
exit status if mkinitrd failed (which typically happened in the kernel 
package's %post when mkinitrd found it didn't have any available loop 
devices to use).

For Fedora 4 and 5 (some people just won't move on...) I also needed a 
tweaked util-linux package with %post tweaked to return a zero exit 
status. I think this may have been a package ordering issue as the %post 
script was getting "command not found" errors for things in /bin like 
touch, chown, and chmod.


One other curiosity I noticed whilst looking at these issues was that 
mock silently refuses to overwrite an existing file if you try to do it 
using config_opts['files'], even if that file is empty. So it's not 
possible for instance to set up a custom /etc/fstab in the chroot this 
way, since mock has already created an empty one by this time. What's 
the reasoning behind this?

Paul.