Dear all, binary packages are built from unpacked sources through a simple interface that combines targets of the debian/rules file and environment variables, to build packages whose structure is documented in our Policy. What about applying the same logic for building source packages?
This would require to specify the formats 1.0 (and its minor updates), 3.0 (quilt) and 3.0 (native) in a more formal way, but I think that it would be a good to have them documented anyway, and it would solve the controversy about debian/source/format: either this file is necessary for a source package to conform to the format 1.0, or it is not. It would also clarify the logic in the 3.0 (variant) name scheme. For instance, if the 3.0 (native) format is updated to 3.1 (native), will the quilt variant stay 3.0 or become 3.1 with no changes? With a simple debian/rules target, for instance ‘source’, the conflict about the source package formats can be made much milder, because it will be the choice of the maintainer to use or not dpkg-dev, debian/source/format, and the automatic patch production system. This solution would bring do-o-cracy back in the loop, with the dpkg-dev maintainers free to implement a solution that respects documented standards (that they are in the first line to shape), and the package maintainers free to use another way if they dislike the approach taken by dpkg-dev. While the Debian infrastructure does not build source packages, such a switch from ‘dpkg-buildpackage’ to ‘debian/rules source’ would be quite distruptive in the maintainers workflows, so it would probably need some time to adapt the toolchains, but apparently the mood is on a mass-transition of our packages anyway… Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100528011316.gb21...@kunpuu.plessy.org
