On Fri, Feb 17, 2017 at 12:32:54PM +0900, Mamoru TASAKA wrote:
>
>
> ----- 元のメッセージ -----
> > 差出人: "Richard Shaw" <hobbes1069@xxxxxxxxx>
> > 宛先: "Development discussions related to Fedora" <devel@xxxxxxxxxxxxxxxxxxxxxxx>
> > 送信済み: 2017年2月17日, 金曜日 12:21:07
> > 件名: GRIPE: A package is not FTBFS if the dependencies can't be installed
> >
> > I received a FTBFS[1] on one of my packages for the F26 rebuild only to
> > find out the only reason it failed (that I know of thus far) is that not
> > all the dependencies could be installed.
> >
> > The root cause seems to be that not all dependent packages were rebuilt
> > when boost was updated to 1.63. Since I maintain said package I'm taking
> > care of it now...
>
> But in that case, such package is actually FTBFS (because BR cannot be installed).
> You have to modify dependency package by yourself or urge maintainers of such
> packages to modify them to resolve FTBFS on your package.
>
> The correct way to show this is to make FTBFS bug on your package blocked by
> ("Depends on") bug reports for such depdendency package.
Filing bugs for transitive FTBFS during a mass rebuild isn't
particularly helpful as it is done now. Instead of the current generic
text, it'd be great if the bug could indicate that the failure was
because some dep is FTBFS. If those bugs could be made to
depend on the FTBFS bugs of the deps, that'd be even nicer.
I think that's another case where we do the easy thing by opening bugs,
without taking into account the amount of wasted maintainer attention on an
issue that they cannot (without provenpackager privs) actually solve themselves.
Zbyszek
> > Is there an easy way to segregate failures in root.log (exit !=0) versus a
> > real build failure?
> >
> > It may be a bit pedantic but I don't like getting assigned bugs saying the
> > package can't be built from source when in fact, compilation never started
> > to begin with because the dependencies could not be met.
> >
> > Richard
> >
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1423104
> >
>
> Regards,
> Mamoru
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
