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.
Tim
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
