Bug#1095231: apt,dpkg: two different meanings for the jargon term "component"
Package: apt,dpkg
Severity: wishlist
Prompted by recent discussion on #debian-devel:
We have two different jargon meanings for "component" in the dpkg/apt
packaging ecosystem, which seems like a source of confusion.
In dpkg-source format 3.0 (quilt) with a multiple-upstream-tarball
package, a component is the identifier for a secondary .orig tarball,
and equivalently, the subdirectory of the source tree into which it
unpacks. For example in `apt source yquake2`, which combines several
closely-related upstream projects:
yquake2_8.41+dfsg.orig.tar.gz
yquake2_8.41+dfsg.orig-ctf.tar.gz
yquake2_8.41+dfsg.orig-rogue.tar.gz
yquake2_8.41+dfsg.orig-xatrix.tar.gz
yquake2_8.41+dfsg-1.debian.tar.xz
yquake2_8.41+dfsg-1.dsc
the components are ctf, rogue and xatrix. I don't think this term
is necessarily load-bearing API in dpkg itself, but it's part of the
configuration file syntax in at least git-buildpackage and uscan. I'm
not aware of any other jargon terms being used this particular concept.
Meanwhile, in /etc/apt/sources.list.d/*.sources and in apt archive
maintenance software like dak and reprepro, a component is something like
main, contrib or universe, referred to in Policy as an "archive area"
and in the Debian Social Contract as an "area". To add to the confusion,
dpkg's deb-src-control(5) uses part of the Section field to store the
archive area, and apt's apt-ftparchive(1) uses Sections to configure
the list of archive areas (but a section is something different, like
libdevel or x11).
This can result in true statements that don't appear to make sense, like
the fact that changing a package's component requires ftp team approval,
but changing a packages's components does not :-)
Would it be possible for one project or the other to introduce a new name
for what it now calls components, and eventually deprecate the old name?
For example apt could introduce "Archive-Areas: main contrib", turn
Components into an alias for that, and eventually deprecate Components.
(I'm not suggesting that it should ever actually be removed entirely:
there is probably too much inertia for that.)
Or, dpkg could start referring to the parts of a multiple-upstream-tarball
as something else (subdirectories? subprojects? extra upstreams?), and
encourage projects like git-buildpackage and uscan to prefer that name
and deprecate calling it a component.
Obviously there would be significant backwards compatibility considerations
to take into account, either way, so this is not a trivial change.
smcv
Reply to: