Re: pbulk resolving stage ALWAYS failes

[Tobias Nygren <tnn%NetBSD.org@localhost>]

On Sat, 22 Dec 2007 11:39:35 +0200
Aleksey Cheusov <cheusov%tut.by@localhost> wrote:

>  >>  >> One of my favourite:
>  >>  >> 
> http://mova.org/~cheusov/pub/pkgsrc-pbulk/Debian-etch/current/log/20071210.1550/gzip-1.3.12
>  >> 
>  >> > Oops. My fault :-) Fixed.
>  >> 
>  >> Heh. You silently ignored this bug for many months and, may be, years.
> 
> > No, at most two month.
> 
> This doesn't matter. I personally don't use pkgsrc version of gzip.
> There are TONS of other bugs seen on Linux or Solaris or Interix
> or... that are not fixed for many years. And you know this.
> 
> I stated that ALL bugs have the same priority, all they should be
> fixed, all they should be visible (e.g. reported by pbulk), but
> neither of them should lead to stop ENTIRE bulk build.

Instead of stating should this and should that, why don't you implement
the suggested change and post a diff. There could even be a
configuration switch to toggle the feature. That way developers and
bulkbuilders can pick the behaviour they want.

I do agree that it is painful to have 6 hours of pbulk scanning wasted
because of some trivial error in a package that you don't really care
about. But the core problem from my point of view isn't that it stops,
it's that bmake isn't very efficient at what it does, CPU-wise.
Parsing Makefiles shouldn't need to be this computationally difficult.
.oO( Maybe some kind of parse cache could speed it up ... )

-Tobias