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
signature.asc
Description: signature
