Re: Changes as first-class objects

[Russ Allbery <rra@debian.org>]

Raphael Geissert <geissert@debian.org> writes:

> But before you start working on it I'd like to bring up one of the
> points I mentioned on <[🔎] hhm40o$qt6$1@ger.gmane.org>: why not turn .dsc
> files into another file type that lintian checks handle?  The scheduler
> and the frontend will need to be modified so that .dsc and .changes
> files parsing is done _after_ they are checked.

I was thinking about that and should respond to that separately outside of
the context of that large thread.  I see a couple of drawbacks to doing
this, one aesthetic and one functional, but they're both drawbacks that we
may be able to work around.

* Aesthetically, a source package is one "thing."  It's represented as a
  varying number of files bound together by the *.dsc file, but it's
  conceptually a single unit.  If the dsc is checked separately, what is
  the combination of the upstream and Debian diff or tarball that would
  also be checked separately?  It's not a source package; it's a sort of
  ill-defined part of a source package.

* Functionally, we want to eventually add a way to check a working tree
  before it's been turned into a source package.  This at first looks like
  a good reason to separately out the dsc file, since this is sort of a
  source package without a dsc file, except that the closer one looks, the
  less this appears to be true.  For instance, we will want to run the
  checks/fields checks in this case against the contents of debian/control
  instead of the fields in the dsc file, since we won't have a dsc file
  but we don't want to skip all of those checks.  (But we *wouldn't* want
  to do that in the case that we *do* have a dsc file.)

Considering the dsc file separately from the source package leaves
something behind that looks sort of like a working tree, so it may be that
we can find some way to deal with the checks/fields problem (handle it
entirely in the collection layer, maybe, and distinguish between the
partial source package and the working tree in some other way with a
different package type).

I'm not sure if these are really good arguments to not do it, but I do
want to be sure we know both what all the pieces are going to be called,
how this affects which checks are run, and how this will continue to work
when checking a working tree.

> P.S. private/TODO needs to be updated.

Yeah, my tentative plan is to update it in conjunction with responding to
the other long message, using it to record the things that we've agreed
on.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>