Re: Toward binpatch (was Re: multiple DESTDIRs)

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

> The original subject was confusing.  What I meant here is binpatch.  Think
> we'll find a critical bug just after releasing NetBSD 6.0.  Think it's one
> line change in source code.  It'd be nice if we release the patch as a binary
> (archive).  Better if it's a binpatch.

Then you should call it
"completely reproducible binary builds for binary patch"
etc.

I think perry@ has/had some idea about it.

> Having multiple DESTDIRs is not the goal; it's one of solutions.  An obvious
> idea would be use a VCS to version DESTDIR.  But I think it's a bit overkill.

To implement such a new infrastructure, we need the following process:
(1) describe your purpose or actual problem to be solved
(2) mention your idea how to solve it
(3) design it and request comment
(4) implement it and call for review

It looks you are just saying about (2).

> > "Comparing two DESTDIRs" can be done manually, can't it?
> > Why/how should it be handled in toolchain?
> 
> Because I want to know how releng builds their binpatches (if they do).
> Because I don't want releng to do it manually.  Because many NetBSD users do
> their own release engineering too.  Both administrators & embedded developers.

You don't mention your design at all, so I can't comment about your idea.

Where should it be handled?
By build.sh targets?
bsd.foo.mk rules?
Scripts under src/distrib?
Local scripts as used on releng servers?

> Sharing a standard way would be a big win.

I'm not asking policy, but your idea of design for your purpose.
---
Izumi Tsutsui