You may a lot of good points. But I think we should try to decouple "this package messes up the bulk build" from "we'd be better off if these bits were removed". I usually find it's easier to start from something that almost works, and a dangling dependency usually means one has to package that dependency, or find where it went. Typically upstreams just add code and dependencies, and structural changes are not so big. If bulk builds won't start becuase there is a package with a dangling dependency, then that sounds like a bug. I don't know if adding BROKEN=depends on zope3 which has been removed would avoid the breakage, or if dropping it from wip/Makefile would suffice. I don't mean to suggest that a packag shouldn't be removed if it would be reasonable to remove it based on understanding the package's situation, including health of upstream, whether the package could reasonably be fixed, etc. (Your including pango caused me to think that at least there was one package that really should be kept.) I'm not as up on bulk builds as I should be. Do you mean old-style bulk, pbulk, or distbb, and what happens when there is a package with an unresolved dependency?
Attachment:
pgpRgw9zxT79b.pgp
Description: PGP signature
------------------------------------------------------------------------------ Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
_______________________________________________ pkgsrc-wip-discuss mailing list pkgsrc-wip-discuss%lists.sourceforge.net@localhost https://lists.sourceforge.net/lists/listinfo/pkgsrc-wip-discuss