On Wed, Feb 05, 2025 at 03:49:03PM +0000, Simon McVittie wrote: > 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 :-)
I don't think there's a meaningful overlap in practice where the use of the term is ambiguous. > > 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.) The name was picked over 20 years ago, and changing it now would generate more friction than the overlap with dpkg's term currently has. We want stuff to be easy to use, and having two ways to do it generally isn't. > 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. I think the colloquial verbiage is "additional orig tarball", because frankly nobody cares about remembering the name for it, that's also significantly reducing the impact of it. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
