Bug 1265873
Summary: | fedora-release has acquired a dependency on /bin/sh | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Ian Wienand <iwienand> | ||||
Component: | fedora-release | Assignee: | Stephen Gallagher <sgallagh> | ||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 23 | CC: | dennis, jdisnard, kevin, pbrobinson, sgallagh, zbyszek | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2016-07-20 15:29:51 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | 1266166 | ||||||
Bug Blocks: | |||||||
Attachments: |
|
Description
Ian Wienand
2015-09-24 02:25:48 UTC
I took a look at this behavior today. We are looking at a modification[*] to how we perform this action. It actually turns out that the solution provided by [2] introduced other issues (specifically when more than one fedora-release-$PRODUCT package is installed) and we need to account for them as well. It is unclear that we will be able to remove the requirement on /bin/sh however. Even with the new mechanism, we will still need at least a %post section somewhere to properly determine the proper symlink. For a little more background on the current problem, the reason we introduced [2] above was because there were situations where it was possible for /etc/os-release to be a dangling symlink until %posttrans time. This caused problems for systemd and systemctl which relied on some information from os-release. As a result, we were forced to write the default symlink into the standard package. Unfortunately, what this means is that on every upgrade, the fedora-release-$PRODUCT packages would have to replace the os-release file again once their %post fired. But if you have more than one of the fedora-release-$PRODUCT packages installed on the system, then you end up with the os-release symlink pointing at whichever of them is processed first in the RPM transaction (usually the earliest in the alphabet). This causes an unexpected change in behavior. Fortunately, few people hit this, since most people stick with only having a single fedora-release-$PRODUCT package on their systems, but it is still a problem. So the mechanism we're considering now is to have anaconda write out /usr/lib/variant at install-time, which we will then have fedora-release read during %post to ensure that it is pointing at the correct os-release file. But this still means that fedora-release will need a dependency on /bin/sh to process it. So unfortunately that does result in a circular dependency through fedora-release->bash->basesystem->setup. I'm not sure how to resolve it. We *could* stick with only having the fedora-release-$PRODUCT packages check the variant file in %post, I suppose, but I don't really like that this leaves the possibility that some packages will still have access to the wrong os-release if they occur in the transaction between the fedora-release and fedora-release-$PRODUCT phases. [*] https://bugzilla.redhat.com/show_bug.cgi?id=1266166 Couldn't we redo this in lua? Like https://fedoraproject.org/wiki/Packaging:Directory_Replacement scriptlets? Thanks for the update. There may well be better ways to bootstrap a system. My particular issues is with diskimage-builder where you can see in [1] the general idea of "chroot rpm --initdb; yum install --destdir=chroot fedora-release fedora-repos; yum install --destdir=chroot yum ..." A similar idea in [2] with lxc containers [1] https://git.openstack.org/cgit/openstack/diskimage-builder/tree/elements/yum-minimal/root.d/08-yum-chroot [2] https://github.com/lxc/lxc/blob/master/templates/lxc-fedora.in (In reply to Kevin Fenzi from comment #2) > Couldn't we redo this in lua? > > Like https://fedoraproject.org/wiki/Packaging:Directory_Replacement > scriptlets? Oh, interesting. I wasn't aware of the lua loophole (luaphole?) for scriptlets. I'll see if I can rework the scriptlets that way before Final Freeze. curious what is diskimage-builder and specifically what does it do? we already have a few tools for image building we really need to stop inventing new ones to do so. I am just guessing based on the name what its functionality is. @Dennis -- sorry for the late reply diskimage-builder [1] is sort of a catch-all tool for building blank base-images and having specific "elements" to bring in support for various things. You can see how we more-or-less bootstrap the system in [2] large parts of openstack depend on it, including triple-o and the upstream CI environment. so we're kind of stuck with it :) [1] http://docs.openstack.org/developer/diskimage-builder/ [2] https://git.openstack.org/cgit/openstack/diskimage-builder/tree/elements/yum-minimal/root.d/08-yum-chroot FYI, this is still on my radar to rewrite the scripts in LUA, I just haven't been able to make the time lately. Probably in the new year. our supported tools for building disk images are livemedia-creator and oz/imagefactory I suspect that what you are using will not work soon anyway, at least not give you satisfactory results, yum has not support for weak dependencies and will not be getting any support for them. From my point of view this is a broken design and we should figure out how to move to something supportable. |