Hide Forgot
I would like to open this bugreport in advance - before the work shows up in the repositories - and hope to get an ear for the problems that comes with said "summary". In the past couple of days a bunch of packages have shown up in the repositories that rely on "rich dependencies". Sadly this caused a lot of things to break for us (and our use cases) and we don't really know how to proceed because there is no going back and no going further for us anymore. A detailed explaination and dialog can be found in the bugreport below: https://bugzilla.redhat.com/show_bug.cgi?id=1317481 Sadly using rich dependency will break 3rd party package management as well as yum (which is still commonly used - as long as dnf won't catch up with missing stuff). We really don't know what to do anymore and howto solve this issue currently.
I think we have to use the rich dependencies in the glibc-langpack-.. packages. Therefore, I think dnf needs to be fixed if it still lacks important stuff.
(In reply to Mike FABIAN from comment #1) > I think dnf needs to be fixed if it still lacks important stuff. I fully understand that glibc-langpack-* needs rich dependencies for proper package management and as you might read in above bugreport (the one with strike through), you see that I (and others) already opened bugs about the use cases we have with yum and thus like to have the same use cases in dnf as well. Sadly close one year has gone and the missing components are still not implemented - yet. We deal with package management, system integration and administration and we *urgently* need to deal with stable packages (e.g. Fedora 22) as well as RawHide packages *today*. We have an automated "environment" that deals with all package management related things on its own (running for years now). There is *no* and I repeat *no* alternative for us at the moment, than continuing using yum until dnf improves with the missing stuff. If the packages start adopting rich dependencies then we end up with huge problems here (at our side). We can't simply wait another half or one year until dnf catches and risking a long outtime. We depend on a working package manager and dependency resolver today. I would really liked that this "issue" has been better communicated and thought through - before everyone jumps on the rich dependency wagoon.
(In reply to Ali Akcaagac from comment #2) > If the packages start adopting rich dependencies then we end up with huge > problems here (at our side). We can't simply wait another half or one year > until dnf catches and risking a long outtime. The glibc team has improved the locale subpackaging support by using rich dependencies and the flexibility and benefits that they bring. These improvements can be used to make minimal cloud installs with only ~3MB of locales as opposed to ~113MB default. This is a real gain for all users with containers or cloud images. How do we balance the benefit that rich features bring to all of our other users against your requirements? Who is "we" in the sentence above? Do you represent a large group of users? Are there more vendors like you that are having problems? I understand the difficulty you face, and software changes and updates like this are not easy. I do not plan to remove the rich dependencies from glibc unless there is a very strong and compelling reason. Does such a reason exist?
(In reply to Carlos O'Donell from comment #3) > I do not plan to remove the rich dependencies from glibc unless there is a > very strong and compelling reason. Does such a reason exist? I would say "yes" ... and I tried to cover the issues as described in the closed kde bug above (the closed one). We are providing systems integration, administration and some other things and wrote an entire infrastructure around yum to automate all our processes as far as possible. Fedora was benefiting from this because we were able to react on package dependency issues very quickly and thus provided valuable reports here on bugzilla. With Fedora 22 the new DNF package manager was introduced as default and YUM at the same time got marked deprecated. This caused us to run into deep problems because we had change huge chunks of - for years working code - to replace YUM by DNF. This worked for most parts of our infrastructure. Sadly one of our main use cases are still *not* covered by DNF which still forces us to stay with YUM. Problem case: ============= - DNF is missing a global "--downloaddir" feature. We rely on this feature, which is introduced by YUM because we keep pre-downloaded packages on a different system and YUM was able to deal with the --downloaddir directory to resolve and skip already downloaded packages. We can not switch to DNF because of this missing feature. Bugreport here: https://bugzilla.redhat.com/show_bug.cgi?id=1203491 - DNF offers a "download" feature that also covers a "--destdir" feature. This could solve our issues. Sadly the "download" feature can't deal with group meta packages. Bugreport here: https://bugzilla.redhat.com/show_bug.cgi?id=1209638#c14 The Bugreport has been marked as duplicate of other bugs even before we were able to explain the use cases correctly. We can not switch to DNF because of this missing feature. So either the globel downloaddir *or* the "download" feature dealing with group meta packages. - YUM offers exactly the things we need. Sadly we can't use it anymore because it lacks the support of "rich dependencies". Please note the following! To clearify myself again. We are all for DNF and really like to switch the missing bits of our hard work - and for years flawlessly working infrastructure to DNF today (if we can). We are all pro DNF and like it so far (even if it caused us a lot of technical trouble because we had to change things). The current situation can only be solved like this: =================================================== 1) Have YUM improved so it understands "rich dependencies". or 2) Have DNF improve to support a global "--downloaddir" feature. or 3) Have DNF "download" feature support download of group meta packages. Neither 1, 2 or 3 exist! I started working on a small quick and dirty replacement for the group download feature, which results that our well written infrastructure (the scripts that automate our processes) end up becoming a "clusterfuck - hackfest" because we are unsure whether we can still cover flawless dependency resolving and package catching: I even filled a Bugreport about this a couple of days ago: https://bugzilla.redhat.com/show_bug.cgi?id=1317564 Note: The above "hack" has been nailed down because we are in desperate urge that our working stuff is continue to operate *somehow*. But this is clearly not the clean proper intended way we would have thought of. From the above closed KDE bug you learn, that even KDE has stepped away from using rich dependencies because it even breaks *other* things such as other "yum-based" tools like "mash", which *they* rely on. Now a simple question back: =========================== - What now ? Bugs has been reported (many) months back. Use cases has been described the best we could describe (followed by slight language and grammar issues). Comming back to the *strong and compelling* issue: ================================================== "Yes" because it breaks things (as 3rd party stuff, other yum based Fedora packages and external written infrastructure (or administrating stuff or code or name it as you like)) ... ... where there is *no* alternative solution offered that covers the use cases. We are not talking about missing features as in "never existed before". We are talking about missing features that has been covered by the old but dropped by the new (causing things to break). And following the Bugreports (or featurerequiest) filled by others (against DNF). I can clearly say that I am not alone here. Again: What now ?
(In reply to Ali Akcaagac from comment #4) > Again: What now ? Lack of planning on your part does not constitute an emergency on our part. It it not a new problem that software infrastructure changes with time and that you need to keep moving forward with such infrastructure. Particularly in the case of Fedora which rebases every 6 months with a release you must work actively with the community to support or contribute the features you need. Choosing to stay with yum because your use cases are not supported by dnf was a choice you made. You need to immediately file a Fedora Packaging Committe[1] ticket to have this issue discussed and eventually escalated to Fedora Engineering Steering Committee [2]. You must get higher level visibility for your problem, otherwise packagers can deny your requests and keep using rich deps to support language packs. I'm marking this CLOSED/WONTFIX for now. [1] https://fedoraproject.org/wiki/Packaging_Committee?rd=Packaging:Committee [2] https://fedoraproject.org/wiki/Fedora_Engineering_Steering_Committee?rd=Development/SteeringCommittee