Do people not care about broken dependencies?

[Igor Gnatenko]

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…

[Brian (bex) Exelbierd]

On Sun, Jun 9, 2019 at 5:18 PM Igor Gnatenko
<ignatenkobrain(a)fedoraproject.org&gt; 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail] 


-- 
Brian "bex" Exelbierd (he/him/his)
Fedora Community Action & Impact Coordinator
@bexelbie | http://www.winglemeyer.org
bexelbie(a)redhat.com | bex(a)pobox.com

[Fabio Valentini]

On Sun, Jun 9, 2019, 18:06 Igor Gnatenko <ignatenkobrain(a)fedoraproject.org&gt;
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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>

[Igor Gnatenko]

On Sun, Jun 9, 2019 at 7:03 PM Fabio Valentini <decathorpe(a)gmail.com&gt; wrote:
>  On Sun, Jun 9, 2019, 18:06 Igor Gnatenko <ignatenkobrain(a)fedoraproject.org&gt; 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(a)lists.fedoraproject.org
>> To unsubscribe send an email to devel-leave(a)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/[e-mail]
>
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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/[e-mail]

[Fabio Valentini]

On Sun, Jun 9, 2019, 19:59 Igor Gnatenko <ignatenkobrain(a)fedoraproject.org&gt;
wrote:

>  On Sun, Jun 9, 2019 at 7:03 PM Fabio Valentini
> <decathorpe(a)gmail.com&gt;
>  wrote:
>  >
>  > On Sun, Jun 9, 2019, 18:06 Igor Gnatenko <
>  ignatenkobrain(a)fedoraproject.org&gt; 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(a)lists.fedoraproject.org
>  >> To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  >
>  > _______________________________________________
>  > devel mailing list -- devel(a)lists.fedoraproject.org
>  > To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>

[Miro Hrončok]

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".

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Vít Ondruch]

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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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/[e-mail]

[Igor Gnatenko]

On Mon, Jun 10, 2019 at 11:31 AM Vít Ondruch <vondruch(a)redhat.com&gt; 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(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)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/[e-mail]
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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/[e-mail]

[Dan Horák]

On Mon, 10 Jun 2019 11:35:52 +0200
Igor Gnatenko <ignatenkobrain(a)fedoraproject.org&gt; wrote:

>  On Mon, Jun 10, 2019 at 11:31 AM Vít Ondruch
> <vondruch(a)redhat.com&gt;
>  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(a)lists.fedoraproject.org
> > > To unsubscribe send an email to
> > > devel-leave(a)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/[e-mail]
> > _______________________________________________
> > devel mailing list -- devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)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/[e-mail]
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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/[e-mail]

[Neal Gompa]

On Mon, Jun 10, 2019 at 8:31 AM Dan Horák <dan(a)danny.cz&gt; wrote:
>  On Mon, 10 Jun 2019 11:35:52 +0200
>  Igor Gnatenko <ignatenkobrain(a)fedoraproject.org&gt; wrote:
>
>  > On Mon, Jun 10, 2019 at 11:31 AM Vít Ondruch <vondruch(a)redhat.com&gt;
>  > 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!

[Dan Horák]

On Mon, 10 Jun 2019 08:34:16 -0400
Neal Gompa <ngompa13(a)gmail.com&gt; wrote:

>  On Mon, Jun 10, 2019 at 8:31 AM Dan Horák <dan(a)danny.cz&gt;
> wrote:
>  >
>  > On Mon, 10 Jun 2019 11:35:52 +0200
>  > Igor Gnatenko <ignatenkobrain(a)fedoraproject.org&gt; wrote:
>  >
>  > > On Mon, Jun 10, 2019 at 11:31 AM Vít Ondruch <vondruch(a)redhat.com&gt;
>  > > 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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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/[e-mail]

[Neal Gompa]

On Mon, Jun 10, 2019 at 9:33 AM Dan Horák <dan(a)danny.cz&gt; wrote:
>  On Mon, 10 Jun 2019 08:34:16 -0400
>  Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>
>  > On Mon, Jun 10, 2019 at 8:31 AM Dan Horák <dan(a)danny.cz&gt; wrote:
>  > >
>  > > On Mon, 10 Jun 2019 11:35:52 +0200
>  > > Igor Gnatenko <ignatenkobrain(a)fedoraproject.org&gt; wrote:
>  > >
>  > > > On Mon, Jun 10, 2019 at 11:31 AM Vít Ondruch <vondruch(a)redhat.com&gt;
>  > > > 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.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Dan Horák]

On Mon, 10 Jun 2019 09:41:39 -0400
Neal Gompa <ngompa13(a)gmail.com&gt; wrote:

>  On Mon, Jun 10, 2019 at 9:33 AM Dan Horák <dan(a)danny.cz&gt;
> wrote:
>  >
>  > On Mon, 10 Jun 2019 08:34:16 -0400
>  > Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  >
>  > > On Mon, Jun 10, 2019 at 8:31 AM Dan Horák <dan(a)danny.cz&gt; wrote:
>  > > >
>  > > > On Mon, 10 Jun 2019 11:35:52 +0200
>  > > > Igor Gnatenko <ignatenkobrain(a)fedoraproject.org&gt; wrote:
>  > > >
>  > > > > On Mon, Jun 10, 2019 at 11:31 AM Vít Ondruch
>  > > > > <vondruch(a)redhat.com&gt; 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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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/[e-mail]

[Adam Williamson]

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(a)danny.cz&gt;
> wrote:
>  > On Mon, 10 Jun 2019 11:35:52 +0200
>  > Igor Gnatenko <ignatenkobrain(a)fedoraproject.org&gt; wrote:
>  > 
>  > > On Mon, Jun 10, 2019 at 11:31 AM Vít Ondruch <vondruch(a)redhat.com&gt;
>  > > 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.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Nico Kadel-Garcia]

On Mon, Jun 10, 2019 at 8:31 AM Dan Horák <dan(a)danny.cz&gt; wrote:
>  On Mon, 10 Jun 2019 11:35:52 +0200
>  Igor Gnatenko <ignatenkobrain(a)fedoraproject.org&gt; wrote:
>
>  > On Mon, Jun 10, 2019 at 11:31 AM Vít Ondruch <vondruch(a)redhat.com&gt;
>  > 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.

[Neal Gompa]

On Tue, Jun 11, 2019 at 11:08 PM Nico Kadel-Garcia <nkadel(a)gmail.com&gt; wrote:
>  On Mon, Jun 10, 2019 at 8:31 AM Dan Horák <dan(a)danny.cz&gt; wrote:
>  >
>  > On Mon, 10 Jun 2019 11:35:52 +0200
>  > Igor Gnatenko <ignatenkobrain(a)fedoraproject.org&gt; wrote:
>  >
>  > > On Mon, Jun 10, 2019 at 11:31 AM Vít Ondruch <vondruch(a)redhat.com&gt;
>  > > 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.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Nico Kadel-Garcia]

On Wed, Jun 12, 2019 at 3:21 AM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  On Tue, Jun 11, 2019 at 11:08 PM Nico Kadel-Garcia <nkadel(a)gmail.com&gt; wrote:
>  >
>  > On Mon, Jun 10, 2019 at 8:31 AM Dan Horák <dan(a)danny.cz&gt; wrote:
>  > >
>  > > On Mon, 10 Jun 2019 11:35:52 +0200
>  > > Igor Gnatenko <ignatenkobrain(a)fedoraproject.org&gt; wrote:
>  > >
>  > > > On Mon, Jun 10, 2019 at 11:31 AM Vít Ondruch <vondruch(a)redhat.com&gt;
>  > > > 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.

[Neal Gompa]

On Wed, Jun 12, 2019 at 6:03 AM Nico Kadel-Garcia <nkadel(a)gmail.com&gt; wrote:
>  On Wed, Jun 12, 2019 at 3:21 AM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  >
>  > On Tue, Jun 11, 2019 at 11:08 PM Nico Kadel-Garcia <nkadel(a)gmail.com&gt; wrote:
>  > >
>  > > On Mon, Jun 10, 2019 at 8:31 AM Dan Horák <dan(a)danny.cz&gt; wrote:
>  > > >
>  > > > On Mon, 10 Jun 2019 11:35:52 +0200
>  > > > Igor Gnatenko <ignatenkobrain(a)fedoraproject.org&gt; wrote:
>  > > >
>  > > > > On Mon, Jun 10, 2019 at 11:31 AM Vít Ondruch
> <vondruch(a)redhat.com&gt;
>  > > > > 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.


-- 
真実はいつも一つ！/ Always, there's only one truth!

[Vít Ondruch]

Dne 10. 06. 19 v 11:35 Igor Gnatenko napsal(a):
>  On Mon, Jun 10, 2019 at 11:31 AM Vít Ondruch
> <vondruch(a)redhat.com&gt; 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(a)lists.fedoraproject.org
>>> To unsubscribe send an email to devel-leave(a)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/[e-mail]
>> _______________________________________________
>> devel mailing list -- devel(a)lists.fedoraproject.org
>> To unsubscribe send an email to devel-leave(a)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/[e-mail]
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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/[e-mail]

[Felix Schwarz]

+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 Williamson]

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.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Tim Flink]

On Mon, 10 Jun 2019 11:03:56 +0200
Felix Schwarz <fschwarz(a)fedoraproject.org&gt; 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