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
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
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
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
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
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
6 matches
Mail list logo