Re: Changes as first-class objects
Russ Allbery wrote:
>
> 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.
After thinking for a while, I think .dsc files should be treated as "source
descriptors" which can be checked in isolation. Source packages would
continue to be defined as a combination of a .dsc and one or more tarballs.
> * 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.)
Even if we have both the .dsc and debian/control, I think we should check
them both.
.dsc files, just like .changes, are generated by a certain set of tools that
change as time passes by and they can be modified by a person or other
tools. That's what makes me vote in favour of checking both parts
independently; we can't tell for sure that they are both equivalent to each
other.
>
> 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).
If we check the .dsc separately, then use it to find the other files that
constitute the source package and from that point ignore the existence
of .dsc files we would end with a consistent system.
>
> 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.
>
What do you think?
Cheers,
--
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net
Reply to: