On Fri, 17 Feb 2012, Carsten Hey wrote: > > > The package debianutils already uses such a target and uses 'prebuild' > > > as name. The developers reference could adopt this name. > > > > How would this relate to Policy 4.14 - debian/README.source? > > In general, debian/README.source does not contain information how to > run, for example, autoconf and friends to convert a clean VCS checkout > into a source tree that can be built using dpkg-buildpackage (there are > packages that require this).
The truth is that the tree is prepared by the clean target. It's function is, *in practice*, to reset the tree for a build, including the first build. I suspect a lot of packages will malfunction (fail to build or produce subtly defective builds) if you do not do this. The clean target can easily arrange for destructive changes to non-autogenerated source (i.e. those that cannot be redone on every build) to happen only once. > The section's first sentence reads: > | If running dpkg-source -x on a source package doesn't produce ..., > | creating a debian/README.source documentation file is recommended. > > Mentioning such a target in debian/README.source seems to be a good > thing, but it does not match the current definition in the policy. If > this gets added to the developer's reference, suggesting to add an > according note to debian/README.source seems to be reasonable, despite > not perfectly fitting a definition in the policy. But if it ends up in > the policy (either in section "4.14 - debian/README.source" or section > "4.9 - debian/rules" and using the words "may" or "optional"), I assume > it would be hard to find a wording that justifies mentioning this target > in debian/README.source, but not explaining how to run autoconf manually > to be able to build the package. > > The intention of this bug report is to unify the name of a target that > might be used more often soon, and it is not sufficient to reach this > goal if we rely on package maintainers to document the target they use > in debian/README.source. I have nothing against separating the clean target into a "prebuild" target (that will have to run when the clean target is invoked for the first time at the very least). But I do wonder how useful this separate "prebuild" target would really be? You still need to run the clean target anyway to do anything useful... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120218121124.gb20...@khazad-dum.debian.net
