Re: Toward binpatch (was Re: multiple DESTDIRs)

[Masao Uebayashi <uebayasi%tombi.co.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.

I know.

> > 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).

I know.  I'm just saying ideas at the moment.

> > > "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.

You said "show me examples" so I wrote examples (use cases).  Or did you mean
example code?

Masao

-- 
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635