Re: dnf replacing yum and dnf-yum

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

 



On Wed, Apr 8, 2015 at 12:11 PM, Tim Lauridsen <tim.lauridsen@xxxxxxxxx> wrote:
>
>
> On Wed, 8 Apr 2015 at 11:05 drago01 <drago01@xxxxxxxxx> wrote:
>>
>> On Tue, Apr 7, 2015 at 6:37 PM, Adam Williamson
>> <adamwill@xxxxxxxxxxxxxxxxx> wrote:
>> > On Tue, 2015-04-07 at 18:33 +0200, drago01 wrote:
>> >> On Tue, Apr 7, 2015 at 6:00 PM, Reindl Harald <h.reindl@xxxxxxxxxxxxx
>> >> > wrote:
>> >> >
>> >> >
>> >> > Am 07.04.2015 um 17:53 schrieb Ralf Corsepius:
>> >> > >
>> >> > > On 04/07/2015 05:07 PM, Kevin Fenzi wrote:
>> >> > > >
>> >> > > > dnf's default behavior is like yum with --skip-broken already.
>> >> > >
>> >> > >
>> >> > > WHAT?
>> >> > >
>> >> > > --skip-broken is a band-aid to work around packaging mistakes
>> >> > > and bugs
>> >> > > and NOT be the default.
>> >> > >
>> >> > > IMO, this kind of behavior is not helpful and therefore should
>> >> > > be reverted
>> >> >
>> >> >
>> >> > +1
>> >> >
>> >> > that's unacceptable and leads in burry *real* problems resulting
>> >> > in sonner
>> >> > or later security updates are broken and nobody take snotice soon
>> >> > enough
>> >>
>> >> The bug is elsewhere though ... i.e. that is even possible to push
>> >> updates with broken deps.
>> >> Rawhide is a different story but everything that goes through bodhi
>> >> (stable releases and branched) should simply refuse pushes with
>> >> broken
>> >> deps.
>> >
>> > This is easier said than done. We don't have a perfect dependency
>> > checker and it's not at all easy to write one. tflink and John Dulaney
>> > have more details if you're interested, but yes, this is not a trivial
>> > thing we can just wave a wand and make happen.
>>
>> We do have dep solvers otherwise no one would notice that a dep is
>> broken ever. (like libsolv + hawkey).
>> So what bodhi should do is to ask "has this package all dependencies
>> satisfied with base + updates + other packages in this push" for every
>> package in the push.
>> If the answer is "no" for a package cancel the push; remove it;
>> restart and only push the once that has satisfied deps.
>> Report the failed once to the maintainers so that they can fix it.
>>
>
> It is not so simple, you have to test all combinations for packages
> requiring an updated package and all the packages there requires someting
> provided by previous version of the package, with thousend of packages and
> multiple packages providing the same stuff, it is an almost impossible task.

Did you even read what I wrote?
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [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