Stuart Prescott <stu...@debian.org> writes: > I know policy is not about mandating implementation details, but > maintainers do find the specific examples in ยง4.9.1 to be useful -- it > would be good if a practical pointer on how nodoc could be implemented > by the maintainer were included as part of this change. At the very > least, a warning about what might need to be done to pull this off would > be worthwhile.
I would really like to bail on this for right now. I agree with what you're saying, but there are apparently some 300 packages in the archive that are using this successfully, and the goal here is to document existing practice. In the long run, this will probably be replaced with build profiles, so we'll have an opportunity to revisit and add more useful information. There currently aren't any tools for Policy to point people at. If we were to modify the proposed language along these lines, I would lean towards adding the warning and making it clearer that implementing this option is strictly optional, just to keep people from naively attempting too hard to implement the target. > At the risk of scope creep on this proposal, is it worth a quick chat > with the debhelper maintainers? Whatever debhelper does or doesn't > implement is going to significantly influence current practice and, in > the spirit of policy documenting practice, it would be good to include > the likely implementers in this discussion. It would seem important to > have a feasible implementation that doesn't require us reverting to a > debian/rules listing out every dh_* command in the sequence and then > decorating that with lots of conditionals. I think these are all good things to do, but I think blocking the Policy change on this is making the best the enemy of the good, and the most likely outcome of pursuing this is months more of delay before documentation of something people are already doing makes it into Policy so that we can agree on how to spell it. So, I don't want to discourage people from doing all these things, but I'd rather merge what we have, maybe with some tweaks to make it clear it's optional, and then improve it later. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87zjelut0d....@hope.eyrie.org
