On Wed, Jun 12, 2019 at 3:21 AM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > On Tue, Jun 11, 2019 at 11:08 PM Nico Kadel-Garcia <nkadel@xxxxxxxxx> wrote: > > > > On Mon, Jun 10, 2019 at 8:31 AM Dan Horák <dan@xxxxxxxx> wrote: > > > > > > On Mon, 10 Jun 2019 11:35:52 +0200 > > > Igor Gnatenko <ignatenkobrain@xxxxxxxxxxxxxxxxx> wrote: > > > > > > > On Mon, Jun 10, 2019 at 11:31 AM Vít Ondruch <vondruch@xxxxxxxxxx> > > > > wrote: > > > > > > > > > > There used to be sent nagging email about broken dependencies, but > > > > > it is not sent anymore. I last received such email on 11th of March > > > > > 2018, so probably we don't really care ... > > > > > > > > The problem with that check is that it just checks if all dependencies > > > > are provided by other packages, but it doesn't check if they can be > > > > installed at the same time. So if I would have package with Requires: > > > > foo + Conflicts: foo, that check won't tell anything. > > > > > > > > Same applies to rich dependencies "with", it just checks if one > > > > condition is provided by anything so this check is not useful for > > > > packages with rich dependencies at all… > > > > > > IIRC the original problem was that repoclosure used yum underneath which > > > didn't understand rich/weak deps at all. Do we still wait on a tool > > > using dnf/libsolv to provide equivalent functionality as repoclosure? > > > > "Weak" dependencies make the problem insuluble. > > No, they don't. Weak dependencies are not hard to deal with. > There are two ways to treat them in repoclosure: treat them as > Requires or ignore them. Right now, we ignore them, but we could > easily modify our repoclosure to treat them as Requires. This is not a complete test. To be complete, it includes the combinatorial complexity of all the different components, installed one by one, in deifferent sequiences, with weak dependencies turned on and off for each different component, each version of the component, and all the different components that may be obsoleted, added, or conflicted with the *next* update. It makes the overall problem intractable, if not insoluble. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
