Hi,

Quoting HW42 (2016-12-19 07:37:00)
> So you (at least josch and ntyi) seem to prefer to have the user facing part
> in sbuild/pbuilder and the common functionality in some kind of library. How
> should the "library" interface look like for sbuild?

pbuilder is written in bash, so a plain-text interface via stdin/stdout would
be preferrable, I guess. The tool figuring out the right snapshot timestamps
could just write an apt sources.list in deb822 format on standard output. Even
if the builder doesn't use the apt resolver, the deb822 format is easy to parse
and thus any required information can be extracted from it.

I also came up with another question:

sbuild/pbuilder/debrebuild are given a .buildinfo file. But that file does not
necessarily include a reference to a .dsc. What shall be done in that case?

The current debrebuild script will auto-generate the filename of the .dsc from
the Source and Version fields of the .buildinfo file. Though the resulting .dsc
might accidentally come from a different build. Is this okay?

Other ways to solve this problem include:

 - only accept .buildinfo files that include the .dsc filename and checksum

    $ builder foo.buildinfo
    E: foo.buildinfo does not reference a source package

 - accept .changes files that reference both the .buildinfo and the .dsc

    $ builder foo.changes
    I: .changes file references a .buildinfo, will verify checksums at the end

 - make .buildinfo files a second-class citizen which are passed *in addition*
   to a .dsc

    $ builder foo.dsc --use-buildinfo=foo.buildinfo

 - accept .buildinfo files, autogenerate the .dsc filename but allow to
   override it via the command line

    $ builder foo.buildinfo --use-dsc=foo.dsc

Thoughts?

Thanks!

cheers, josch

Attachment: signature.asc
Description: signature

_______________________________________________
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Reply via email to