Guillem Jover:
> On Sun, 2015-02-01 at 10:46:50 +0100, Jérémy Bobbio wrote:
> > Guillem Jover:
> > > * I'm not entirely sure if this really makes sense as a different
> > > file, but at least given that it's controlled by dpkg-buildpackage
> > > we can always fold it into dpkg-genchanges if we deem that's a
> > > better course of action. So it seems fine this way for now.
> >
> > dpkg-genbuildinfo as a different file from dpkg-genchanges in the source
> > code or *.buildinfo as different control files from *.changes?
>
> I meant as different control files. The *.changes file records
> information and the files for a release, I don't see why we could not
> also store the environment used to produce those changes there. Looked
> at it that way it does not seem so much like a misnomer to me?
>
> If the archive has to be changed to store and accept *.buildinfo, it
> could as well be changed to make the stored *.changes files public.
>
> In any case as mentioned above, the current split file is fine for
> experimentation, as we can always fold it back in. But would be nice
> to decide before we start to deploy this in dpkg, the archive, etc.
When we began thinking about reproducible builds in 2013, the idea was
indeed to record the build environment in *.changes. At some point, it
occured to me that this was mixing two purposes into one.
*.changes files describe changes to the archive. *.buildinfo files
describe a specific build. The first has only a historical purpose once
the changes have been applied. When the description of a build stays
meaningful until the files are removed from the archive.
*.changes could (can?) describe changes that
are not directly related to building a package. With the current
proposal about buildinfo signatures, *.changes could be used to add an
extra certification after the initial upload:
https://wiki.debian.org/ReproducibleBuilds/BuildinfoSpecification#buildinfo_signatures
> > > * Some of the information in this file trigger my privacy alarm bells,
> > > for example the Build-Path field.
> >
> > Absolutely.
> >
> > For packages shipping DWARF symbols, this is only making the issue more
> > visible.
>
> AFAICS the DWARF spec says that any file references can be either
> absolute or relative, so I guess the problem here is that the build
> process or the toolchain is passing absolute paths. The fix here would
> be to use relative paths instead.
I have not seen any tool using a relative path so far. But that's an
interesting area to explore.
> > The initial idea was to push for a canonical build location for Debian
> > packages. Adding `Build-Path` to buildinfo gives us the ability to
> > change this location later on.
> >
> > In any cases, considering the build path as part of the build
> > environment removes several hard to solve issues. Maybe if there's
> > enough people feeling like tackling them, we can revisit this decision.
>
> To me this seems like sidestepping a real issue, by neutralizing it
> with the recorded setting. The same route could be taken for other
> things like uname, etc, when in this case I think it makes sense to
> get rid of the different build path. But then I don't think I can
> volunteer myself to fix this so… :)
I'm with you here. It just felt like an acceptable compromise for the
time being. If someone would patch debugedit to sort the string table
after patching, I guess it becomes doable again. It felt like real hard
work when I took a shot at it.
--
Lunar .''`.
lunar@debian.org : :Ⓐ : # apt-get install anarchism
`. `'`
`-
Attachment:
signature.asc
Description: Digital signature