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

Johannes Schauer josch at debian.org
Thu Nov 10 14:35:55 UTC 2016


Hi,

Quoting Mattia Rizzolo (2016-11-10 12:17:39)
> On Thu, Nov 10, 2016 at 11:46:29AM -0200, Johannes Schauer wrote:
> > In fact, for the sake of making source packages cross buildable, many
> > Architecture:all packages are right now being converted into
> > Architecture:any M-A:same packages.
> As you know I'm kinda not in-sync with the cross/bootstrap/… projects, but
> did you ever thought about some other solutions not inolving lying?

and by lying you mean to put architecture independent stuff into architecture
dependent binary packages, I guess?

The underlying problem is the dual nature of the Architecture field. It is at
the same time a handy way to de-duplicate data on our mirrors that is in fact
the same across all architectures but is also used to contain packages with
architecture independent code. Both these meanings are merged into a single
field but not always both meanings are true. Picture for example an
Architecture:all package containing a Python script exposing a specific
architecture through the code it contains or the architecture-specific Python
modules it requires. Are we then not lying to package this software as
Architecture:all because indeed that script is *not* architecture independent
in its functionality?

The underlying problem is, that Architecture:all means that the package is
considered to be of the native architecture. The proposed fix for this is the
interpreter proposal by Helmut Grohne:
https://wiki.debian.org/Multiarch/InterpreterProposal

But that solution has several drawbacks as you can read of here:

https://wiki.debian.org/Multiarch/MissingRationale#Why_not_adopt_the_interpreter_proposal.3F

A missing reason against this proposal is also:

We currently don't have anybody with enough time at hand to implement this
change in dependency resolution in all affected software. To get a list of
packages that handles dependencies, you can look at this table:

https://wiki.debian.org/BuildProfileSpec#Document_status

For a volunteer-driven project like Debian I'd deem such an intrusive change
quit herculean. Converting Architecture:all packages to
Architecture:any/M-A:same on the other hand is simple and works today.

> > Though I fear that there might exist cases where S_D_E is used
> > legitimately. After all, if there were no legitimate uses of S_D_E, then
> > why was it introduced instead of just patching all source packages to be
> > completely independent of an input timestamp?
> 
> Personally, I see SDE as non-legitimate is just about all cases.
> Timestamps in build processes should just die.  Probably the only case I
> support of it is to normalize mtimes of files inside archives, cause you
> can't just zero them or the world breaks.
> In fact, very few days ago I sent a patch to an upstream of mine to
> remove __DATE__/__TIME__ usage, regardless of g++ respecting SDE now.
> 
> I.e. my solution to manpages and files embedding times is to get rid of those
> times.

I might agree with you but if I wanted to start pushing such an effort I'd have
to have enough time on my hand to prepare patches against everything which I do
not have. Plus, even with patches, lots of upstreams might just disagree with
me and think it's a good idea to embed timestamps in the build results. So SDE
is a workaround that is a good compromise to even make those developers happy
that insist to have timestamps in their build results.

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/9ec6413a/attachment.sig>


More information about the Pbuilder-maint mailing list