Re: What makes a .changes file source-only? [and 1 more messages]
Guillem Jover writes ("Re: What makes a .changes file source-only?"):
> IMO, in theory, a source-only .changes is primarily defined by its
> Architecture field containing only "source" as value. As a consequence
> of only containing references to a .dsc and any further file referenced
> within.
>
> Even though this might seem backwards, my reasoning is that the
> Architecture field values are extremely well defined, while going
> based on filenames requires extension scrapping, which while also
> well defined always seems a bit icky to me.
That's why I thought we should ask.
> Of course, in practice, if going just by the Architecture field, you
> need to trust that the software generating the .changes (and the .dsc)
> is not buggy, and the entity that commissioned its creation is not
> trying to bypass the checks. But for BY-HAND artifacts that do not
> follow the well defined name_version_arch.type filename form, then
> this will not be represented in the Architecture field, which is
> something that should probably be fixed by annotating the field with
> some value (probably the host architecture to be conservative).
I think this is a bug, then, in dpkg. If Architecture is `source',
then there shuld not be any by-hand artifacts.
> Also, even though I could imagine someone injecting non-source artifacts
> from within the debian/rules clean target even for source only builds,
> I'd consider that to be just broken.
It's rather weird that a source package build still looks at the
debian/files.
> For source-only, I think going by a whitelist is indeed more sensible,
> but I'd just check whether there is a .dsc, and whether the rest of the
> references in the .changes are just the files referenced in the .dsc.
I like this suggestion. Thanks.
But:
> > We observed that .buildinfo files are included in purportedly
> > source-only changes files by `dpkg-buildpackage -S`.
> >
> > Is this correct? Why are they included in source-only uploads?
>
> Yes, this is correct, although I've noticed again (as I did in the
> past but seem to have forgotten) that the dpkg-buildpackage man page
> is out-of-sync regarding this, which I'll be fixing. In any case the
> other day I just added a FAQ entry, given that this seems a recurring
> question. :)
>
> <https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Why_are_.buildinfo_files_always_generated_with_dpkg-buildpackage.3F>
>
> If there's anything that does not seem to hold, or is unclear I'm happy
> to clarify it further.
Well, of course, your suggestion to check the .dsc against the
.changes will trip over the .buildinfo.
Also, as you write in your FAQ entry:
By default dpkg-buildpackage does active tasks such as cleaning via
debian/rules, and makes sure that the dependencies from Build-Depends
are satisfied as these are needed by the clean target. In addition the
clean target can perform any kind of action that will affect the
source package, which is also part of the build, and should be by
default also reproducible
I think what you mean here is that one might have a source package
which is not a fixed point under `debian/rules clean' for all
reasonable combinations of the build-deps. I think this is a buggy
package but in practice it seems that many packages are buggy in this
way.
Indeed IMO it is a defect of our overall design that it the concept of
a `non-reproducible source package' even exists. Sources are the
input to builds, not an output, so the question of reproducing them
does not arise. That our system as a whole can sometimes mutate the
source package all by itself is a bug.
However, these are not considerations for dgit in this context, since
what dgit uploads is always guaranteed to be equal to the input.
Often the user will have dgit use `git clean' rather than rules clean;
and even if they don't, dgit will check that the results were the
same.
That is, even with the .buildinfo, someone who gets the .dsc cannot
know whether the rules clean target is correct (or to put it another
way, under what conditions the source tree is a fixed point under
rules clean), because dgit has not necessarily run rules clean at all.
I'm sure there are other vcsish tools which have the same property.
(Also, and I hesitate to make this argument because of course I
support reproducible builds, but: if the .buildinfo is not useful,
then it's an unwarranted privacy violation.)
So I think for `dgit push-source', there should be no .buildinfo ?
At least, unless dgit ran the clean target.
This suggests to me that dgit push-source should use dpkg-source
rather than dpkg-buildpackage, as you note in later in the FAQ entry:
If the intention is to just produce a source package instead of an
actual build to upload, then using dpkg-source is always the better
option.
This wording is a bit unclear. It conflates `build' and `for upload'.
I think regarding `dgit push-source' as a build is perverse.
dgit would have to run dpkg-genchanges.
Alternatively dgit could strip out the .buildinfo, depending on
whether it ran rules clean.
Sean Whitton writes ("Re: What makes a .changes file source-only?"):
> Hello Guillem and Ian,
> > OOC, what would be the purpose of checking what is shipped on a binary
> > upload?
>
> I think Ian just saw the opportunity to add a new sanity check to dgit.
I'm not sure what I was thinking. This now obviously seems a bad
idea.
> Ian: given that BY-HAND uploads could contain a lot of different kinds
> of file, maybe we should stick to the option of only checking purported
> source-only .changes files, abandoning this extra check?
Indeed.
Ian.
Reply to: