[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Toward binpatch (was Re: multiple DESTDIRs)
> > 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"
> 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).
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
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635
Main Index |
Thread Index |