Hello,
I've noticed that people keep pushing updates which have broken dependencies.
For example, python-kombu was updated from 4.6.0 to 4.6.1. Both of those versions have broken dependency "python3.7dist(amqp) >= 2.5.0 ". However, it was built both for F30 and F31 and even submitted to bodhi.
I have more examples…
On Sun, Jun 9, 2019 at 5:18 PM Igor Gnatenko ignatenkobrain@fedoraproject.org wrote:
Hello,
I've noticed that people keep pushing updates which have broken dependencies.
For example, python-kombu was updated from 4.6.0 to 4.6.1. Both of those versions have broken dependency "python3.7dist(amqp) >= 2.5.0 ". However, it was built both for F30 and F31 and even submitted to bodhi.
This looks like a low-hanging fruit job for CI Gating - if the package can't be installed, gate it, barring override.
regards,
bex
I have more examples… _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
On Sun, Jun 9, 2019, 18:06 Igor Gnatenko ignatenkobrain@fedoraproject.org wrote:
Hello,
I've noticed that people keep pushing updates which have broken dependencies.
For example, python-kombu was updated from 4.6.0 to 4.6.1. Both of those versions have broken dependency "python3.7dist(amqp) >= 2.5.0 ". However, it was built both for F30 and F31 and even submitted to bodhi.
I have more examples…
Hi Igor,
I have some additional examples of this as well. I think this is most often caused by automatically generated unsatisfied dependencies of binary packages - which don't break the build, but make the package uninstallable.
Fabio
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
On Sun, Jun 9, 2019 at 7:03 PM Fabio Valentini decathorpe@gmail.com wrote:
On Sun, Jun 9, 2019, 18:06 Igor Gnatenko ignatenkobrain@fedoraproject.org wrote:
Hello,
I've noticed that people keep pushing updates which have broken dependencies.
For example, python-kombu was updated from 4.6.0 to 4.6.1. Both of those versions have broken dependency "python3.7dist(amqp) >= 2.5.0 ". However, it was built both for F30 and F31 and even submitted to bodhi.
I have more examples…
Hi Igor,
I have some additional examples of this as well. I think this is most often caused by automatically generated unsatisfied dependencies of binary packages - which don't break the build, but make the package uninstallable.
If you mean Rust ones, those are intentional because we do not indent to ship them to the users... However, we need to build them somewhere.
But yeah, people just don't notice this.
Fabio
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
On Sun, Jun 9, 2019, 19:59 Igor Gnatenko ignatenkobrain@fedoraproject.org wrote:
On Sun, Jun 9, 2019 at 7:03 PM Fabio Valentini decathorpe@gmail.com wrote:
On Sun, Jun 9, 2019, 18:06 Igor Gnatenko <
ignatenkobrain@fedoraproject.org> wrote:
Hello,
I've noticed that people keep pushing updates which have broken
dependencies.
For example, python-kombu was updated from 4.6.0 to 4.6.1. Both of those versions have broken dependency "python3.7dist(amqp) >= 2.5.0 ". However, it was built both for F30 and F31 and even submitted to bodhi.
I have more examples…
Hi Igor,
I have some additional examples of this as well. I think this is most
often caused by automatically generated unsatisfied dependencies of binary packages - which don't break the build, but make the package uninstallable.
If you mean Rust ones, those are intentional because we do not indent to ship them to the users... However, we need to build them somewhere.
No, I didn't attempt to be passive-aggressive here ;) My issues were caused by python package updates, as well.
But yeah, people just don't notice this.
Fabio
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
On 09. 06. 19 17:17, Igor Gnatenko wrote:
Hello,
I've noticed that people keep pushing updates which have broken dependencies.
For example, python-kombu was updated from 4.6.0 to 4.6.1. Both of those versions have broken dependency "python3.7dist(amqp) >= 2.5.0 ". However, it was built both for F30 and F31 and even submitted to bodhi.
I have more examples…
Sometimes such packages won't install for several releases at all, but if I argue to retire them, it is blocked because "it is important package".
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 ...
Vít
Dne 09. 06. 19 v 17:17 Igor Gnatenko napsal(a):
Hello,
I've noticed that people keep pushing updates which have broken dependencies.
For example, python-kombu was updated from 4.6.0 to 4.6.1. Both of those versions have broken dependency "python3.7dist(amqp) >= 2.5.0 ". However, it was built both for F30 and F31 and even submitted to bodhi.
I have more examples… _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
On Mon, Jun 10, 2019 at 11:31 AM Vít Ondruch vondruch@redhat.com 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…
Vít
Dne 09. 06. 19 v 17:17 Igor Gnatenko napsal(a):
Hello,
I've noticed that people keep pushing updates which have broken dependencies.
For example, python-kombu was updated from 4.6.0 to 4.6.1. Both of those versions have broken dependency "python3.7dist(amqp) >= 2.5.0 ". However, it was built both for F30 and F31 and even submitted to bodhi.
I have more examples… _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
On Mon, 10 Jun 2019 11:35:52 +0200 Igor Gnatenko ignatenkobrain@fedoraproject.org wrote:
On Mon, Jun 10, 2019 at 11:31 AM Vít Ondruch vondruch@redhat.com 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?
Dan
Vít
Dne 09. 06. 19 v 17:17 Igor Gnatenko napsal(a):
Hello,
I've noticed that people keep pushing updates which have broken dependencies.
For example, python-kombu was updated from 4.6.0 to 4.6.1. Both of those versions have broken dependency "python3.7dist(amqp) >= 2.5.0 ". However, it was built both for F30 and F31 and even submitted to bodhi.
I have more examples… _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
On Mon, Jun 10, 2019 at 8:31 AM Dan Horák dan@danny.cz wrote:
On Mon, 10 Jun 2019 11:35:52 +0200 Igor Gnatenko ignatenkobrain@fedoraproject.org wrote:
On Mon, Jun 10, 2019 at 11:31 AM Vít Ondruch vondruch@redhat.com 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?
I already ported spam-o-matic to DNF, however the multi-arch stuff somehow got broken in DNF shortly after I wrote the code, so that's not working as intended. Someone needs to fix it. I already tried to figure it out, but I have no clue why it's broken.
-- 真実はいつも一つ!/ Always, there's only one truth!
On Mon, 10 Jun 2019 08:34:16 -0400 Neal Gompa ngompa13@gmail.com wrote:
On Mon, Jun 10, 2019 at 8:31 AM Dan Horák dan@danny.cz wrote:
On Mon, 10 Jun 2019 11:35:52 +0200 Igor Gnatenko ignatenkobrain@fedoraproject.org wrote:
On Mon, Jun 10, 2019 at 11:31 AM Vít Ondruch vondruch@redhat.com 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?
I already ported spam-o-matic to DNF, however the multi-arch stuff
do you mean multi-lib, i.e. it would work still for non-multilib arches (eg. aarch64 or ppc64le)?
Dan
somehow got broken in DNF shortly after I wrote the code, so that's not working as intended. Someone needs to fix it. I already tried to figure it out, but I have no clue why it's broken.
-- 真実はいつも一つ!/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
On Mon, Jun 10, 2019 at 9:33 AM Dan Horák dan@danny.cz wrote:
On Mon, 10 Jun 2019 08:34:16 -0400 Neal Gompa ngompa13@gmail.com wrote:
On Mon, Jun 10, 2019 at 8:31 AM Dan Horák dan@danny.cz wrote:
On Mon, 10 Jun 2019 11:35:52 +0200 Igor Gnatenko ignatenkobrain@fedoraproject.org wrote:
On Mon, Jun 10, 2019 at 11:31 AM Vít Ondruch vondruch@redhat.com 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?
I already ported spam-o-matic to DNF, however the multi-arch stuff
do you mean multi-lib, i.e. it would work still for non-multilib arches (eg. aarch64 or ppc64le)?
No, I meant what I said. I mean multi-arch. That is, checking across all architectures from an x86_64 host.
That said, aarch64 and ppc64le are multi-lib arches, we just don't ship it in Fedora this way.
For example, OpenMandriva is shipping armv7hnl + aarch64 multi-lib. We just don't because we started earlier when most aarch64 systems couldn't support 32-bit arm at all.
On Mon, 10 Jun 2019 09:41:39 -0400 Neal Gompa ngompa13@gmail.com wrote:
On Mon, Jun 10, 2019 at 9:33 AM Dan Horák dan@danny.cz wrote:
On Mon, 10 Jun 2019 08:34:16 -0400 Neal Gompa ngompa13@gmail.com wrote:
On Mon, Jun 10, 2019 at 8:31 AM Dan Horák dan@danny.cz wrote:
On Mon, 10 Jun 2019 11:35:52 +0200 Igor Gnatenko ignatenkobrain@fedoraproject.org wrote:
On Mon, Jun 10, 2019 at 11:31 AM Vít Ondruch vondruch@redhat.com 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?
I already ported spam-o-matic to DNF, however the multi-arch stuff
do you mean multi-lib, i.e. it would work still for non-multilib arches (eg. aarch64 or ppc64le)?
No, I meant what I said. I mean multi-arch. That is, checking across all architectures from an x86_64 host.
I see, thanks,
Dan
That said, aarch64 and ppc64le are multi-lib arches, we just don't ship it in Fedora this way.
For example, OpenMandriva is shipping armv7hnl + aarch64 multi-lib. We just don't because we started earlier when most aarch64 systems couldn't support 32-bit arm at all.
-- 真実はいつも一つ!/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
On Mon, 2019-06-10 at 08:34 -0400, Neal Gompa wrote:
On Mon, Jun 10, 2019 at 8:31 AM Dan Horák dan@danny.cz wrote:
On Mon, 10 Jun 2019 11:35:52 +0200 Igor Gnatenko ignatenkobrain@fedoraproject.org wrote:
On Mon, Jun 10, 2019 at 11:31 AM Vít Ondruch vondruch@redhat.com 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?
I already ported spam-o-matic to DNF, however the multi-arch stuff somehow got broken in DNF shortly after I wrote the code, so that's not working as intended. Someone needs to fix it. I already tried to figure it out, but I have no clue why it's broken.
The issues for this are:
https://pagure.io/releng/issue/6365 https://pagure.io/releng/issue/7931 https://bugzilla.redhat.com/show_bug.cgi?id=1565257
if anyone can help fix it, we'd definitely appreciate that. There are definitely people who care about getting these reports and fixing dependencies, but we also care about twenty other things at the same time, and it's very difficult to do all of them.
On Mon, Jun 10, 2019 at 8:31 AM Dan Horák dan@danny.cz wrote:
On Mon, 10 Jun 2019 11:35:52 +0200 Igor Gnatenko ignatenkobrain@fedoraproject.org wrote:
On Mon, Jun 10, 2019 at 11:31 AM Vít Ondruch vondruch@redhat.com 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.
On Tue, Jun 11, 2019 at 11:08 PM Nico Kadel-Garcia nkadel@gmail.com wrote:
On Mon, Jun 10, 2019 at 8:31 AM Dan Horák dan@danny.cz wrote:
On Mon, 10 Jun 2019 11:35:52 +0200 Igor Gnatenko ignatenkobrain@fedoraproject.org wrote:
On Mon, Jun 10, 2019 at 11:31 AM Vít Ondruch vondruch@redhat.com 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.
On Wed, Jun 12, 2019 at 3:21 AM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Jun 11, 2019 at 11:08 PM Nico Kadel-Garcia nkadel@gmail.com wrote:
On Mon, Jun 10, 2019 at 8:31 AM Dan Horák dan@danny.cz wrote:
On Mon, 10 Jun 2019 11:35:52 +0200 Igor Gnatenko ignatenkobrain@fedoraproject.org wrote:
On Mon, Jun 10, 2019 at 11:31 AM Vít Ondruch vondruch@redhat.com 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.
On Wed, Jun 12, 2019 at 6:03 AM Nico Kadel-Garcia nkadel@gmail.com wrote:
On Wed, Jun 12, 2019 at 3:21 AM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Jun 11, 2019 at 11:08 PM Nico Kadel-Garcia nkadel@gmail.com wrote:
On Mon, Jun 10, 2019 at 8:31 AM Dan Horák dan@danny.cz wrote:
On Mon, 10 Jun 2019 11:35:52 +0200 Igor Gnatenko ignatenkobrain@fedoraproject.org wrote:
On Mon, Jun 10, 2019 at 11:31 AM Vít Ondruch vondruch@redhat.com 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.
No. It's the same level of complexity for repoclosure and installcheck for even just strong dependencies.
You can make the assumption that if you flip the weak attribute strong for repoclosure and installcheck purposes that you've caught all the necessary cases for dealing with dependency shifts like obsoletes.
This is a problem I've stared deep in the face for literally years at this point. While you're technically correct that there's tons of variation for usage, there is not for specifically dependency checking.
Rich dependencies with boolean clauses are the ones that make things complex, not weak dependencies. That's when you need to start "testing" dependency statements.
Dne 10. 06. 19 v 11:35 Igor Gnatenko napsal(a):
On Mon, Jun 10, 2019 at 11:31 AM Vít Ondruch vondruch@redhat.com 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…
It would be better than nothing ...
Vít
Vít
Dne 09. 06. 19 v 17:17 Igor Gnatenko napsal(a):
Hello,
I've noticed that people keep pushing updates which have broken dependencies.
For example, python-kombu was updated from 4.6.0 to 4.6.1. Both of those versions have broken dependency "python3.7dist(amqp) >= 2.5.0 ". However, it was built both for F30 and F31 and even submitted to bodhi.
I have more examples… _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
+1 to prevent broken dependencies to be pushed into stable. If Fedora aims to be a "polished"/"user friendly" distro users should never have to deal with broken dependencies.
Also packages with broken dependencies should not be part of a release (maybe not auto-retired if they are still ok for other releases). Felix
On Mon, 2019-06-10 at 11:03 +0200, Felix Schwarz wrote:
+1 to prevent broken dependencies to be pushed into stable. If Fedora aims to be a "polished"/"user friendly" distro users should never have to deal with broken dependencies.
This is a very difficult problem. It sounds easy, but it...isn't. I won't go into three pages of detail, but yes, there is no ten minute fix to this at all.
On Mon, 10 Jun 2019 11:03:56 +0200 Felix Schwarz fschwarz@fedoraproject.org wrote:
+1 to prevent broken dependencies to be pushed into stable. If Fedora aims to be a "polished"/"user friendly" distro users should never have to deal with broken dependencies.
Also packages with broken dependencies should not be part of a release (maybe not auto-retired if they are still ok for other releases). Felix
Adam mentioned this elsewhere in the thread, but there are folks who care about this but we also have many other things to take care of.
This is something that is on my radar to add to Fedora CI but there are a bunch of other things which need to be done first and I've not gotten to the point where I've even written down these plans in a coherant fashion.
As we get closer to making it a reality, I'll be writing about it more.
Tim