Control: clone -1 -2 Control: reassign -1 dpkg Control: reassign -2 apt Hi!
On Wed, 2025-02-05 at 18:29:48 +0100, Julian Andres Klode wrote: > On Wed, Feb 05, 2025 at 03:49:03PM +0000, Simon McVittie wrote: > > 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. In the dpkg-source documentation I see it more as a "variable name" to refer to the text to replace with, than a defining term. But it seems I was also unhappy with the naming in the code, and in dpkg commit 52230e6fe98fdd1b2de2651e95d4f7afb74c7fed I renamed the variables from origtar to addonfile, I guess to make room for the subsequent addonsign variable and "addon orig.tar" references in error messages in dpkg commit c5aa5d8e00d076a4ca4b35ab8f2a3eb082bb6cd5. And I think I like «addon» better than «component» for the documentation as well, so I've changed that locally (see the attached patch), and I'm planning on including that in my next push. Let me know if that improves or makes things worse. :) I'm also going to change references in the wiki, at least at <https://wiki.debian.org/Projects/DebSrc3.0>. But… > > 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. … I agree these names are used in different contexts, so of course one can construct possibly ambiguous phrasings, but you can also give enough context to make these clear. :) > > 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? I think it might still make sense for both to rename things to make terminology more clear, so that's why I've cloned the report to apt, but they might decide it's not worth it on their side. > > 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. If it's something that apt parses, then I think it should be fine to transition to something better or more clear (I've also found those terms confusing), if it's something apt emits, then that's going to be a pain and probably not worth it (unless there's a CLI version bump or similar), as the amount of local consumers is going to be hard to measure. > > 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. I think the other common usage is “multi upstream tarball” (aka “MUT”), but I think any of: * addon orig.tar * addon orig tarball * additional orig.tar * additional orig tarball * multi upstream tarball (aka “MUT” in some contexts) might be clear enough, depending on the usage or what it refers to. Thanks, Guillem
From cf9e36e5ffbd65788464d7022acc87ba71386d74 Mon Sep 17 00:00:00 2001 From: Guillem Jover <[email protected]> Date: Thu, 21 Aug 2025 23:35:15 +0200 Subject: [PATCH] man: Switch from .orig-<component>.tar to .orig-<addon>.tar This should make the nomenclature a bit more clear, and matches the current code and error message references. Closes: #1095231 --- man/dpkg-source.pod | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/man/dpkg-source.pod b/man/dpkg-source.pod index 42699eff3..3440fec75 100644 --- a/man/dpkg-source.pod +++ b/man/dpkg-source.pod @@ -590,18 +590,18 @@ an original tarball (B<.orig.tar.>I<ext> where I<ext> can be B<gz>, B<bz2>, B<lzma> and B<xz>) and a debian tarball (B<.debian.tar.>I<ext>). It can also contain additional original -tarballs (B<.orig->I<component>B<.tar.>I<ext>). -I<component> can only contain alphanumeric (‘a-zA-Z0-9’) characters +tarballs (B<.orig->I<addon>B<.tar.>I<ext>). +I<addon> can only contain alphanumeric (‘a-zA-Z0-9’) characters and hyphens (‘-’). Optionally each original tarball can be accompanied by a detached upstream signature (B<.orig.tar.>I<ext>B<.asc> and -B<.orig->I<component>B<.tar.>I<ext>B<.asc>), extraction +B<.orig->I<addon>B<.tar.>I<ext>B<.asc>), extraction supported since dpkg 1.17.20, building supported since dpkg 1.18.5. B<Extracting> The main original tarball is extracted first, then all additional original -tarballs are extracted in subdirectories named after the I<component> +tarballs are extracted in subdirectories named after the I<addon> part of their filename (any pre-existing directory is replaced). The debian tarball is extracted on top of the source directory after prior -- 2.50.1
