On Wed, Apr 29, 2009 at 09:02:33PM +0300, Elad Efrat wrote: [...] > > Given the total lack of history of binary updates in NetBSD, my very own > > opinion is that any such tool should be focused primarily on making the > > production of binary updates as easy as possible. I'm fairly certain > > the users will agree with pretty much anything that will give them > > binary updates they can install and roll back with sustainable pain. > > > > I think the main risk is at the production level. If it is not easy > > enough, it will be too much for the time releng@ and s-o@ have. > > There are more "risks", but let me paste item #4 for the producers > from my original email: > > 4. After the new files are built, generate updates. This is done using > the -G flag. For example, if you just rebuilt for > NetBSD-UP2007-0001, and want to generate updates for it: > > haze -G -U NetBSD-UP2007-0001 > > The updates will show up in the output dir, /tmp by default, and > will be in the form of NetBSD-UP2007-0001-4.0-amd64.tar.gz. > > The process, unless obvious, is like this: > 1. Write the description of the issue -- mostly just the stuff > that'd go into a SA (or use a tool to generate it) > 2. Fix the issue in the code, run the build (or have the autobuild > do it automatically, or whatever) > 3. After the build finished, run a single command (that can probably > be attached to the autobuild very easly) Why didn't anything happen? And please don't take that personally, but if a tool easy to use to do binary updates existed two years ago, why isn't it in use right now? One thing I trust Tonnerre on is that he will try to go all the way and do the necessary pushing on releng@ and maybe admins@ to make the thing actually happen. Not everything is about technical merit or user experience. > > So I'd very much like to see this discussion turn towards the way the > > tools (any of them) can be used by releng@, e.g. how they can be tied to > > the autobuild system, and so on. This is what matters most to me. > > See above. I don't think it should be that hard. > > All that said, we're once again "deciding" on something without > hearing opinions on it. When I wrote my tool I didn't support binary > patches (as opposed to just binary updates that include the replaced We? > object rather than a patch for it) because I don't think we should. That's an implementation detail, as far as I am concerned. > While it's great to have a tool that releng@ or security-officer@ can > easily work with, a part that's just as important is what users are > looking for. Well, duh. But if said users only get to use it every 10 years it's not that useful. (Yeah, I know, duh too.) -- Quentin Garnier - cube%cubidou.net@localhost - cube%NetBSD.org@localhost "See the look on my face from staying too long in one place [...] every time the morning breaks I know I'm closer to falling" KT Tunstall, Saving My Face, Drastic Fantastic, 2007.
Attachment:
pgptpXogLqg2E.pgp
Description: PGP signature