[rb-general] Wished field in buildinfo files (debian)

[Vagrant Cascadian]

On 2018-12-07, Eli Schwartz wrote:
> On 12/7/18 8:41 AM, Vagrant Cascadian wrote:
>> On 2018-12-07, Juan Picca wrote:
>>> Rationale:
>>> To reproduce a package (manually for now) maybe is convenient and easy
>>> for the creation of the schroot used by sbuild an url based in s.d.o
>>> with the timestamp of the build and the distribution used.
>>>
>>> Example:
>>> For example in the buildinfo file for 0ad [2] I would like a field
>>> similar to (name can change):
>>>
>>> Build-Snapshot: /archive/debian/20181203T153211Z testing
>> 
>> The official Debian buildds do not use snapshots.debian.org, and may not
>> even be up to date with the current packages in sid/testing/stable,
>> etc.
>> 
>> So you can only really guess at this information; there's no way to
>> programatically know which appropriate snapshot was used- in fact, there
>> may not even be a single snapshot which captures all of the packages
>> used in the build.
>> 
>> If you're doing a rebuild, I could see this as a useful hint to other
>> rebuilders, if you happen to use one or more Snapshots in the build, it
>> would be useful to record that information. But it would have to be
>> added after dpkg generates the .buildinfo; I doubt you'll be able to get
>> that sort of code into dpkg.
>
> The Arch Linux Archive has unambiguous links to every package. We use
> dated snapshots to provide a view of the package repositories at any
> given time (fully functional as repository mirrors) but also provide a
> non-dated link:
> archive.archlinux.org/packages/f/foo/foo-version-release-architecture.fileextension
>
> Maybe Debian could provide something similar for its snapshots?

The snapshots that Debian provides are actually based on the sha1sum
hash of the files, but they're not used in the "normal" mirrors. The
official build infrastructure doesn't use such snapshots.


>> It's also possible to re-build a package with a different distribution
>> in the changelog file, though this is rare.
>
> Why is this allowed by the tooling, to have multiple packages that claim
> to be the exact same version and distro release?

The official archive prevents this by ensuring non-conflicting
filenames, but other tooling does not.

There's nothing to prevent someone from rebuilding a package locally,
and the corresponding .buildinfo could still be uploaded to some
external service to compare against the official builds.


> Arch does not explicitly have tooling to blacklist this, but we would
> consider it a major bug if someone went ahead and did it anyway.

Which suite/release it gets installed to is actually taken from the
.changes file, not the changelog file in the package, so the two can
have different information. It is generally considered a a bug and/or
undesirable, sure.


> I thought Debian-based distros used the distribution releasename as part
> of the package release field, to prevent these sort of clashes.

Well, packages move from unstable to testing and eventually to stable,
so there's no single "correct" release to target on a per-package
basis. The Release, Packages and Sources files describe which packages
are part of any given suite/release, and the same exact packages may be
included in multiple suites/releases.


live well,
  vagrant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20181207/b2d550d0/attachment.sig>