Re: What is the source code (was: [RFC] General Resolution to deploy tag2upload)
Aigars Mahinovs writes ("Re: What is the source code (was: [RFC] General Resolution to deploy tag2upload)"):
> On Wed, 19 Jun 2024 at 12:57, Gerardo Ballabio
> <gerardo.ballabio@gmail.com> wrote:
> > 1) is the source of a package the current version of the code? [*]
> > 2) is the source of a package the complete history of the project? [**]
>
> That is a very different set of questions and that is based on a
> false premise.
I think you're talking somewhat at cross purposes with Gerardo and
Paul. This subthread is about a wider, more philosophical question:
is the git history, in the general case, a necessary part of "the
source code". I think this isn't a simple question. Gerardo is
pointing out, correctly, that this doesn't depend on the
*representation* of the previous version information.
This subthread isn't about the source package construction question
(which is the real core of the disagreement we have with ftpmster).
On a factual point, though:
> For example, in the git-debrabase workflow that Russ described on
> this list recently the latest checkout would not have any of the
> debian/patches files in it. The patches in this case are represented
> as separate commits in the recent git history that are rebased on
> top of the latest upstream release version commit.
I should point out that with git-debrebase, although the *metadata*
and *unpatched version* information is (in the maintainer's git) only
in the form of commits, the final patches applied version *is*
in the maintainer's git tip - that's what the tree is.
Like I said in my other mail, no matter what your views are on the "is
history part of the source code" question, whether you think the
contents of debian/patches is a necessary part of the source can't
depend on the representation.
Either (for a particular package) the commentary etc. in
debian/patches is not "part of the source code" even though it's
present in the "3.0 (quilt)" package; or (for that package) it *is*
part of the source code even though in the maintainer's git tree it's
only in the history, not in the tree.
I think most users of git-rebrebase think the patch stack, which they
manipulate as a rebasing git branch, is very much part of the source
code. You wouldn't want to try to update to a new upstream version by
just merging the trees, or trying to apply and resolve one mega-diff.
There will be other packages where things are different. One of the
things that's so striking about this area, that we have learned while
developing dgit, is how radically different different people's
workflows and opinions are. Debian contributors who have mostly
worked on their own packages won't have seen this diversity are likely
to (quite understandably) wildly underestimate the diversity and
complexity.
> It has nothing to do with history. Unless you want to do deep dives
> and do git blame research. Something that is not possible with
> Debian source code packages beyond the uploader/maintainer/developer
> boundary.
History diving is an important part of the maintenance and development
of much software, nowadays. Which is why I'm in your "unless":
I think the git history is often an essential part of the source code.
And yes, that means, that for many packages, I think what is published
in the Debian archive as the "source code" is *not* the source code.
It's an intermediate build product.
Ian.
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Reply to: