I just wanted to comment that I don't think the wording should be "You have to implement debugging this way if you are going to support it". Two reasons:
1) Right now policy does not require -g, but only suggests an example, yet everyone is compilg this way. I don't think our developers have to be forced into every possible detail of packaging. Who knows, with the option to do it differently, some one may find a better way. Also, with a suggest, you can always file a wishlist bug to the affect if you want. So they can support either form (their own and the suggested one in policy). The main point being, that most developers _want_ to be standard and will not want to go the extra mile of implementing something completely different than policy suggests that wont get used. Why? because the suggestion is simple and to the point. No overhead in trying to put it into use. If we make it complex (as some suggestions have been) or put a lot of reasoning into the usage then it will get left out, and no one will want it. 2) Perhaps there is no way for that maintainers package to comply exactly with the details of the requirement. I can't think of a place where this would be the case. For one, I do know that some packages get their CFLAGS from a predefined source (e.g perl modules that compile with Makefile.PL). So it isn't really in their control, atleast not easily. Also there may be different cases of what debugging actually is in a package. Perhaps it is a set of scripts, that when generated normally strips out some of the debug code, but can also be generated with the debug code. We don't know, so we can't force this. Now as far as some reservations due to not knowing and "what if" scenarios. I'de just like to say that we can't stop progress due to not knowing what the outcome will be. This proposal has clear advantages (as others have admitted) and saying no simply because there _may_ be a better way, without actually having a better way, is pointless. No one knows what the future will hold for any of the current policy. Countless times we have had great ideas, that not until well down the road are seen as insufficient. Fortunately, this one will atleast be able to back out easily because it is non-obtrusive to how we currently do things (we still get stripped packages without changes). Ben
