Bug 1265873 - fedora-release has acquired a dependency on /bin/sh
fedora-release has acquired a dependency on /bin/sh
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: fedora-release (Show other bugs)
23
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Stephen Gallagher
Fedora Extras Quality Assurance
:
Depends On: 1266166
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-23 22:25 EDT by Ian Wienand
Modified: 2016-07-20 11:29 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-07-20 11:29:51 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
removal of posttrans (1.14 KB, patch)
2015-09-23 22:25 EDT, Ian Wienand
no flags Details | Diff

  None (edit)
Description Ian Wienand 2015-09-23 22:25:48 EDT
Created attachment 1076338 [details]
removal of posttrans

fedora-release in F22 has acquired a dependency on "/bin/sh", for example

---
$ rpm -qpR ./fedora-release-21-2.noarch.rpm
config(fedora-release) = 21-2
fedora-repos(21)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1


$ rpm -qpR ./fedora-release-22-1.noarch.rpm 
/bin/sh
config(fedora-release) = 22-1
fedora-repos(22)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1
---

So after some digging, this started happening at [1] where the %posttrans was introduced to fix up the os-release symlink, thus bringing in the "/bin/sh" dependency.  However, after [2] this has been changed to ship the standard symlink within the package always

Thus I believe the %posttrans section for "fedora-release" package is not actually required?

The reason this is a bit annoying is because of bootstrapping in a chroot environment, where we "rpm -i fedora-release" package as downloaded.  When this requires "/bin/sh" it creates a difficult ordering issue.  It can be worked around with "--nodeps" but it's always nicer to avoid such hacks if possible

[1] https://git.fedorahosted.org/cgit/fedora-release.git/commit/?id=f06cb77a5adab9ba1eae57c09befdf80a00c395b
[2] https://git.fedorahosted.org/cgit/fedora-release.git/commit/?id=8a8444b1123897168932cf10fca0411dcccf66a0
Comment 1 Stephen Gallagher 2015-09-24 12:47:51 EDT
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
Comment 2 Kevin Fenzi 2015-09-24 16:38:06 EDT
Couldn't we redo this in lua? 

Like https://fedoraproject.org/wiki/Packaging:Directory_Replacement scriptlets?
Comment 3 Ian Wienand 2015-09-24 17:21:15 EDT
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
Comment 4 Stephen Gallagher 2015-09-28 10:44:35 EDT
(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.
Comment 5 Dennis Gilmore 2015-09-30 18:05:58 EDT
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.
Comment 6 Ian Wienand 2015-12-07 18:49:19 EST
@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
Comment 7 Stephen Gallagher 2015-12-08 09:14:10 EST
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.
Comment 8 Dennis Gilmore 2015-12-08 13:39:45 EST
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.

Note You need to log in before you can comment on or make changes to this bug.