Source packages: standard formats and interfaces as an alternative to centralisation.
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
Reply to: