No dia 8 de Dezembro de 2010 17:18, Philip Brown <[email protected]> escreveu: > Errr... It should be noted somewhere.. ideally in the naming of the > override mechanism itself... that such overrides, are only TEMPORARY. > file collision is a "hard stop". while you can override collisions > that may be present on the build farm; packages that collide with > other packages present in "current", will not be accepted into > "current".
Right, it's checkpkg's way of displaying errors. In the first phase, checkpkg was displaying just errors: Error: CSWfoo: kittens-missing In the following discussion it was pointed out that checkpkg could also print overrides, so it would be easier for people to work with them. The output started looking like this: Error: CSWfoo: kittens-missing (...) CHECKPKG_OVERRIDES_CSWfoo += kittens-missing After setting checkpkg to this kind of output, it became apparent that the two messages are in fact redundant. One can be derived from the other, and we can as well display just one of them. The more useful one is the override definition, and that's the one which stayed. The output then currently is: CHECKPKG_OVERRIDES_CSWfoo += kittens-missing ...which is both an error report and an override template. For some errors, there are also longer explanations given above. So far, maintainers have been doing a good job reading them carefully and only applying overrides where appropriate. _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
