Sean Whitton <[email protected]> writes: > Hello, > > Andrea Pappacoda [02/Jan 2:18pm +01] wrote: >> Hi all, >> >>> Il giorno 1 gen 2026, alle ore 00:56, Simon Josefsson <[email protected]> >>> ha scritto: >>> If the source name of git-merge-changelog below causes confusion, maybe >>> we could use upstream's other name 'vc-changelog' however as far as I >>> understand, 'vc-changelog' is an umbrella project that currently is only >>> hosting the 'git-merge-changelog' sub-project, so this is not ideal. >> >> What about naming the source package “vc-changelog”, and have it produce the >> git-merge-changelog binary package? > > Possibly the name "VC" in this context comes from Emacs's VC package. > The developers of gnulib and Emacs overlap a fair bit. > > (I don't know if this comment helps any decision making, but I thought > I'd note it.)
Thanks -- I'm mixed between two positions here, because: 1) If the upstream vc-changelog project ever produces more sub-projects and consequently multiple source tarballs for distinct unrelated tools, we couldn't easily track that except as multiple orig.tar components, which seems ugly. I think the general advice is to have one Debian source package for each upstream source tarball, at least in normal cases. So this speaks in favor of picking 'git-merge-changelog' for the source package name. 2) Upstream git repository appears to be layed out to support multiple tools, by having git-merge-changelog/ live in a sub-directory. Since I moved from using the upstream tarballs to using upstream git repository [1], that would actually speak in favor of using 'vc-changelog' as the Debian source package name. Then we could easily add another binary package if another sub-directory with some unrelated tool appears. But that is a internal design choice that can change later, if for some reason using the upstream tarballs turns out to be better than using upstream git. And building two unrelated tools from the same debian/rules file is also problematic, and there is Build-Depends bloat. I'll let this digest until next week and see if there is any new insights, and then just pick a name and do the NEW upload. I think the choice is arbitrary, and that we are prematurely optimizing. But there could be some more serious concern that I missed. /Simon [1] https://salsa.debian.org/debian/git-merge-changelog/-/commit/04d1a1017a32db66006791b88c4578720adf1c5a
signature.asc
Description: PGP signature
