Re: Do people not care about broken dependencies?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 10 Jun 2019 09:41:39 -0400
Neal Gompa <ngompa13@xxxxxxxxx> wrote:

> On Mon, Jun 10, 2019 at 9:33 AM Dan Horák <dan@xxxxxxxx> wrote:
> >
> > On Mon, 10 Jun 2019 08:34:16 -0400
> > Neal Gompa <ngompa13@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?
> > > >
> > >
> > > 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@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
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux