[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pkgsrc-current-destdir Linux 2.6.24-1-686-bigmem/i686 bulk build results 20080829.1720
>> >> Suppose
>> >> 1) you need a package A
>> >> 2) package A depends on B
>> >> 3) B fails => A fails "indirectly"
>> >> In such situtations (in most cases), it makes sense to contact
>> >> maintainer of the package B. This is why your email is there.
>>> No. In any case first person to be responsible for failure of package
>>> is that package maintainer.
>> In most cases dependancy is correct and the real problem is in
>> dependant package. This is why I include a maintainer of the dependant
>> package by default. In general only human can recognize the "right
>> person" to contact. Sometimes bugs in mk/ scripts or buildlinks3.mk or
>> anywhere else may cause the problem.
> Don't talk about "most cases", there're correct ways and incorrect ones.
It is trivially to proof that in most cases maintainer of failed
dependancy is closer to the problem than that of "indirectly" broken
wip/slate and infrastructure failures are rare excludions.
I thought about inclusion of both maintainers. But I didn't do so
because in this case I had problems with 90-columns limit of textual
report.txt. I'll think about how to reorganize this section.
distbb provides separate file that contains only "directly" failed packages
and many other useful META/*.txt files.
$ grep asau@ packages_failed.txt
Best regards, Aleksey Cheusov.
Main Index |
Thread Index |