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

[Mattia Rizzolo]

On Thu, Nov 10, 2016 at 10:22:11AM -0200, Johannes Schauer wrote:
> 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?

Yes, exactly.
In m-a:same packages should only go:
 - arch-specific files that will always be in arch-specific paths and
   have no chances to collide
 - files that will always ever be the same regardless of what
   architectures built it and when, etc (these should really be in
   arch:all binaries though)

The typical example of a m-a:same binary package is a library package.

Do we agree on this?

> 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.

That bug is already more messy than what I usually accept :S

> 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.

Yes.  You have no assurance not only about different versions of
package B in different architectures, but that B package can actually be
completely different across architectures (just think about a different
compiler implementation, one that only works for x86 and one that works
everywhere, B might be virtual).

But ths means nothing.  If a package is m-a:same you're saying that no
matter what that package will always be somehow coinstallable with the
build done for other host architectures that, again, means either files
installed in arch-specif paths, or files that never changes.

> 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.

that's just plain impossible to have, as really often happens that
implementations of stuff varies across archs (for a prectical example,
see OpenMPI vs mpich (mpi-default) or golang vs gccgo or whatever name
has.

> You don't see this problem much in reality because
> 
>  - in general, package versions agree across all architectures

well, no.  generally there is always some arch that is screwed, maybe
not across release architectures, but if you consider all of the archs.
maybe still the majority of packages is in sync across all
architectures, but it's not the norm still (I'd be happy to see data
about this, but it goes way too off topic).

>  - changes that would trigger such content changes are mostly only new major
>    releases of software which also happen rarely

that's the most relevant point, maybe.

>  - 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.

and this.

> 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.

still, if by this a couple of m-a:same binaries is not coinstallable
anymore, imho that m-a:same field is buggy and shouldn't have been used
in first place.

> 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.

binNMUs are very interesting things theory-wise, though :P

-- 
regards,
                        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
more about me:  https://mapreri.org                             : :'  :
Launchpad user: https://launchpad.net/~mapreri                  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pbuilder-maint/attachments/20161110/3441953c/attachment.sig>