Bug#843867: pbuilder: allow passing the timestamp for the new changelog entry for binNMUs

[Johannes Schauer]

Heyho!

Quoting Mattia Rizzolo (2016-11-10 09:31:47)
> On Thu, 10 Nov 2016, 12:20 p.m. Johannes Schauer, <josch at debian.org> wrote:
> > and then packages with the same binNMU number will not be co-installable
> > anymore if they share a file that ends up having different content because
> > of S_D_E.
> 
> I argue that should not be in a ma:same package.

you argue that files with content that changes depending on S_D_E should either
be in architecture specific paths or not be shared across architectures?

You might want to share your rationale for that in #843773 because those files
potentially being shared and then differing between different binNMUs is
currently a problem.

> Reproducible manages and such only exist since 1 year or so, ma:same exists
> since a lot before and before that manages weren't the same.
> 
> Also, imho ma:same packages should be coinstallable regardless of the
> number of binNMUs that happened differently across archs (modulo dpkg not
> being happy, but your idea discards that too).

It's out of the scope of this bugreport but:

If you make binary packages with different binNMU version co-installable (by
using the source package version instead and making sure that the source
version agrees instead of the binary package version) then you will much more
often run into the situation where binary packages are not co-installable
because the files they share contain differing content.

You have this problem already today - even without binNMUs. Suppose a source
package A building binary packages with content that depends on a build
dependency B. If you now build A on all architectures, and one of the
architectures has B in a different version, then the binary packages produced
by A on that architecture will differ from the others and as a result will not
be installable. The only way to get around that would be to schedule package
builds such that what is currently recorded in the Installed-Build-Depends
field of the .buildinfo file is equal across all architectures. We don't have
that yet and maybe it would even be too much hassle to implement because it
would mean that we can only build something new once even the slowest arch has
caught up. You don't see this problem much in reality because

 - in general, package versions agree across all architectures
 - not all binary packages make their content dependent on the version of their
   source package's build dependencies
 - changes that would trigger such content changes are mostly only new major
   releases of software which also happen rarely
 - not many people do co-install packages of different architecture besides
   i386/amd64 which are both very fast arches and thus mostly always in sync.
   If you try to cross-build with much slower arches involved you see this
   problem more often.

But with binNMUs this happens more often because a binNMU might be scheduled
years after the original source upload and might then not be scheduled on all
architectures. In a year, lots of packages in the build dependencies changed
their version and are more likely to have seen major updates.

Yes, binNMUs suck, but the above is my sales pitch not to soften the criteria
by which binary packages are deemed co-installable. If we would, we see less
disagreement on the dependency-solver level but much more disagreement once we
actually try to co-install these packages and then stumble across file content
conflicts.

Thanks!

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/pbuilder-maint/attachments/20161110/10e8a9a7/attachment.sig>