On Mon, Mar 17, 2008 at 09:51:17AM -0700, Bart Smaalders wrote: > >Well, it's a little more fundamental than that - without *some* labelling, > >every kernel change (that is, every new pkg revision of genunix) means > >every kernel module is rebuilt and re-issued too. > > There are a lot of kernel changes that don't affect genunix.
I did clarify what I meant by "kernel change" in the parenthesis. > >The current system has been a significant pain point for the current S10 > >leads - and it's not even being used correctly. There are a number of > >ways we can rethink things, but this is one of those rare things where > >the packaging system impacts directly on the build, so we do need to > >deal with this wrt IPS. > > The packaging system doesn't affect the build here; it's the other way > around. Both are true. The packaging system (or more generally, the content delivery system) affects the build via the patch make-up table. The build affects the packaging system for somewhat more obvious reasons. > Are you saying that even though two builds produce identical versions of a > kernel module, we must always take the later one? No. > >>If necessary, we may need to work on making the CTF construction > >>process more deterministic. > > > >This is extremely difficult for the needs we have in this case, if not > >impossible. > > So what you're implying is that we have to replace all kernel binaries > every time we relink? Or that if I build the same ON software 10 times, > I'll end up with 10 different versions of all the kernel modules which > are not interchangable? If you build the exact same source files with an identical CBE, the CTF will be the same. Anything that changes the type IDs of genunix require either refreshing all dependent modules, or some labelling scheme as is currently used. Perhaps it would be more productive if I ask you how you see this working. In particular, what changes are you going to make to the relevant parts of the kernel Makefiles? regards john _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
