David Holland <dholland-current%netbsd.org@localhost> writes: > On Mon, Jan 05, 2009 at 02:57:00AM +0000, Christos Zoulas wrote: > > >What about structures that have inline time_t members? Otherwise > > >this is a serious issue waiting to be hit. Just consider two different > > >libraries, one old, one new, both using stat(2). > > > > All have been versioned. Including rpc, etc. > > Are we going to do a mass revbump in pkgsrc? Why is this any different that any other change, like base system openssl bump? If we revbump every package, should we be doing this for every incompatible change in every OS pkgsrc runs on? I don't think we've ever (or certainly not usually) done this. One does need to build new packages when the OS changes, at least sometimes. But a revbump won't fix that, because people who rebuild during the bump and then update to current won't get a rebuild. Probably we need to treat the base system as a virtual package with an ABI version and do some sort of unsafe_depends marking when updating the base. For binary packages, I think nuking all existing binary packages for current and starting builds over, plus users of current marking all installed packages unsafe_depends should suffice. pkg_chk or pkg_rr probably needs to learn to do binary replacements of unsafe_depends packages. I think this is all pretty hard and not new and that we shouldn't force fixing it simultaneously the time_t changes.
Attachment:
pgp2he0iiXDIG.pgp
Description: PGP signature