Bug 1317481
| Summary: | plasma-workspace: using rpm rich dependencies incompatible with yum | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Ali Akcaagac <aliakc> |
| Component: | plasma-workspace | Assignee: | Rex Dieter <rdieter> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | jgrulich, kde-sig, me, mfabian, rdieter, than |
| 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-03-15 16:24:33 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: | |||
True, the new rpm rich dependencies used here may only supported by dnf/PackageKit Hmmmm.... .... unfortunately we still heavily rely on using yum because dnf is not feature complete and/or still doesn't offer similar features so we can switch to it .... We are still waiting for dnf to advance with similar capabilities as yum. For more information I'd like to reference to the following *still* open bugreports: https://bugzilla.redhat.com/show_bug.cgi?id=1203491 https://bugzilla.redhat.com/show_bug.cgi?id=1224908 https://bugzilla.redhat.com/show_bug.cgi?id=1229823 https://bugzilla.redhat.com/show_bug.cgi?id=1256313 https://bugzilla.redhat.com/show_bug.cgi?id=1167239 https://bugzilla.redhat.com/show_bug.cgi?id=1227001 https://bugzilla.redhat.com/show_bug.cgi?id=1279185 We were able to switch our (internal) infrastructure from yum to dnf as far as possible. Unfortunately our main use case still depends on yum because of missing features like "--downloaddir" and "group of packages" (metapackages) processing as well as "idling" (halting for infinite hours) in the middle of the download or update/installation process within an automated process. As long as these bugs remain open (and there has been plenty more open dnf woes that I opened in the past), as long we *still* rely on using yum. We rella like changing to dnf today rather than anytime in the future - but sadly we can't. If the new *packages* start adapting some rpm/dnf specific stuff, then we end up being totally *fucked*. s/rella/really/ adjusting summary FYI, langpacks handling in fedora 24 is all moving toward using such rich dependencies (In reply to Rex Dieter from comment #5) > FYI, langpacks handling in fedora 24 is all moving toward using such rich > dependencies We will end up running into deep problems if that happens anytime soon - as we already had by transitioning from Fedora 20 to Fedora 22 and the yum to dnf switch. Possible solutions for the time being is: 1) Have yum support the *relevant* new stuff 2) Have dnf support a general --downloaddir option 3) Have dnf download groupname --destdir --resolve become able dealing with "group" packages We are still waiting for anything of that (one of the three options= to pop up. Bugs has been filled months back. Sadly it's *** very difficult *** talking to the dnf developers. I was sitting down and wrote an alternative approach dealing with this situation. 1) getting rid of yum and switching to dnf entirely. 2) working around the issues (Point: 1 - 3) as described in #6. Sadly the only solution I came up with failed because dnf isn't able dealing with long lists of files. Please find the bugreport as well as test case bash script here: https://bugzilla.redhat.com/show_bug.cgi?id=1317564 We are stuck in a blocking situation where we can't go further nor back. OK, after some discussion onlist and irc, we've decided that we cannot use rich deps in Requires: or Recommends: yet, since it currently breaks yum and yum-based compose tools (like mash, used for updates). I'll update affected packages accordingly, replacing current uses of: Requires: (foo if bar) with simpler Recommends: foo which is (should be!) yum safe. Thanks for the support and sorry for the extra work you've been having now. I'd like to tell you the reasons for depending on yum. We provide some small systems administration work and our "infrastructure" is based around a handful of bash scripts and yum. Error checking, automate update downloading, package management, only downloading what's new and so on. That's also the reason why you keep getting plenty of "please fix if possible" bugzilla entries from me, if packages break dependency. The system reports us such issues. The "infrastructure" worked properly for years under Fedora ... untill ... yes until dnf has shown up and replaced yum ... starting with Fedora 24. We are all for dnf here but sadly we realized that plenty of our use cases are not covered by dnf ... which has caused a lot of problems for us. Wherever possible, we changed to dnf... even simple changes ended up in fatal results like dnf often sending back different exit and return codes in case of issues... This already caused us to *touch* the code that used to work for years. Now by now all scripts (with exception of one → the main one) has been moved over to dnf. The main script consists of: - three different and simple yum calls - outputs a lot of required information with debug and verbose output. This output was easily to be grep'ed and used for further processing. dnf otoh has switched to different process for output and their debug and verbose level are totally ripped out. What used to be a simple 3 liner ended up that we were forced to run "strace" with yum (as preparation for dnf) to grab the NVRA filenames. This part has been changed but caused a lot of work. We are now waiting for dnf to update ... because: - dnf install/update Supports group (metadata) handling. It also has a --downloadonly feature. With yum we used "yum install <group> --downloadonly --downloaddir --debug=3" to have our packages 1) resolve, 2) download, 3) in the correct dir, 4) debug output for further NVRA processing. Unfortunately dnf still lacks the --downloaddir feature. We can't switch! - dnf download <package> --downdir --resolve Supports downloading for package by name. Supports resolving of that package. Supports downloading into a destination directory. Unfortunately it lacks the ability to process groups. We can't switch! Now today I learned about the "rich dependencies". So far yum doesn't seem to support it yet. It's not known by me (because I don't spent much time on the ML), whether it may support it or not. That's why I started to fiddle around with the comps.xml files from Fedora git. I plan to keep working on this, in case everything fails one day: - Use wget to download the file - use xmmlint --xpath capabilities to grab all packages from the groups that we depend on. - create a list of all packages from the groups - pass the list to dnf download <list> --downdir --resolve What has been 3 simple yum calls in the past (and for years) ended up in: - strace / grep for NVRA filenames - wget / xmmlint --xpath - dnf download --downdir --resolve - problems with different return and exit codes between yum vs. dnf ... hacking ... Anyways... Thanks for the support... It gives me time to breathe here... OK, all traces of rich-deps used in any Requires/Recommends should be gone in latest batch of stuff submitted to -testing |
Checking deps for kdelibs.i686 6:4.14.18-1.fc25 - u looking for ('kde-apps-rpm-macros', 'EQ', ('6', '4.14.18', '1.fc25')) as a requirement of kdelibs.i686 6:4.14.18-1.fc25 - u looking for ('kde4-macros(api)', 'EQ', ('0', '2', None)) as a requirement of kdelibs.i686 6:4.14.18-1.fc25 - u looking for ('kdelibs-common', 'EQ', ('6', '4.14.18', '1.fc25')) as a requirement of kdelibs.i686 6:4.14.18-1.fc25 - u looking for ('dbusmenu-qt(x86-32)', 'GE', ('0', '0.9.2', None)) as a requirement of kdelibs.i686 6:4.14.18-1.fc25 - u looking for ('kde-filesystem', 'GE', ('0', '4', '23')) as a requirement of kdelibs.i686 6:4.14.18-1.fc25 - u looking for ('phonon(x86-32)', 'GE', ('0', '4.8.3', None)) as a requirement of kdelibs.i686 6:4.14.18-1.fc25 - u looking for ('qt4(x86-32)', 'GE', ('0', '4.8.7', None)) as a requirement of kdelibs.i686 6:4.14.18-1.fc25 - u looking for ('strigi-libs(x86-32)', 'GE', ('0', '0.7.8', None)) as a requirement of kdelibs.i686 6:4.14.18-1.fc25 - u looking for ('(kde-platform-plugin(x86-32) if plasma-workspace)', None, (None, None, None)) as a requirement of kdelibs.i686 6:4.14.18-1.fc25 - u Error: Invalid version flag: if ---------------------------------- - dependency or repository issue - ---------------------------------- Please fix if possible "if" is not a valid version flag for "yum".