Bug#811064: Please don't do this

2016-01-15 Thread Raphael Hertzog
On Fri, 15 Jan 2016, Wouter Verhelst wrote: > Optionally maybe doing something is a terrible idea if we want Handling a knife is dangerous, but we should not forbid knife. > - reproducible builds > - no surprises on security updates We do have tools to ensure that there are no regressions on

Bug#811064: Please don't do this

2016-01-15 Thread Gergely Nagy
On Fri, Jan 15, 2016 at 1:54 PM, Raphael Hertzog wrote: > On Fri, 15 Jan 2016, Wouter Verhelst wrote: >> If a build-dependency is not available on a given architecture, then the >> package cannot be built on that architecture. Period. If that's a > > Life is not black and

Bug#811064: Please don't do this

2016-01-15 Thread Raphael Hertzog
On Fri, 15 Jan 2016, Gergely Nagy wrote: > How about a compromise? I can enable the ? syntax for .manpages files > only, so it covers this case (provided that manpage installation can > be moved to a .manpages file from .install). > > What do you think? I don't understand your suggestion but I

Bug#811064: Please don't do this

2016-01-15 Thread Wouter Verhelst
Optionally maybe doing something is a terrible idea if we want - reproducible builds - no surprises on security updates - no surprises for people on one architecture who want to do the same on another etc. And I think we do, in all of those cases. If a build-dependency is not available on a

Bug#811064: Please don't do this

2016-01-15 Thread Wouter Verhelst
On Fri, Jan 15, 2016 at 01:54:05PM +0100, Raphael Hertzog wrote: > On Fri, 15 Jan 2016, Wouter Verhelst wrote: > > - reproducible builds > > - no surprises on security updates > > We do have tools to ensure that there are no regressions on all those > fronts. The presence of tools to avoid

Bug#811064: Please don't do this

2016-01-15 Thread Raphael Hertzog
This is getting off-topic for this bug. But the discussion is interesting. On Fri, 15 Jan 2016, Wouter Verhelst wrote: > My point here (but I'll admit that the above sentence doesn't make that > clear) was that *users* who are familiar with a package on one > architecture should not be surprised