Rainer Orth wrote: > Dave, > >> From an installation point of view, we don't currently care much - the >> projects need to arrive at a packaging breakdown which makes sense for >> them. We may choose to bring forward some recommendations or policies >> on package granularity based on the install strategy work I've been >> doing and the package/patch strategy work that's also getting under way, >> but what those might be is speculation at this point and I wouldn't try >> to impose them until they've been written down and reviewed. I don't >> think anything you're suggesting is unreasonable at first glance, though > > ok, fine. I suppose, based on this I can try to go forward either with > Mike Kupfer or with another sponsor once I'm ready with the actual > changes. >
Yeah, you could. Mike (or whomever) should at that point round up code reviewers who own the affected pieces so they consent; my suggestion of the opensolaris-code discussion is mostly to help complete what you were trying to do here, which is to get any major issues identified before you invested too much time in a specific breakdown. >> I wonder if some of the headers should just drop into SUNWhea rather >> than creating new packages for them. > > The problem is that they are missing even from the closed tarballs, so > that's not an option if one wants to allow building SUNWhea even for a > non-closed build. Maybe those omissions are just a mistake and not > required for legal reasons. If so, that would certainly simplify things. > I don't know why they are, but yeah, I see why SUNWhea isn't necessarily the right place to go. >> The movement of files from one package to another between Solaris >> releases is handled by the package history mechanism, which is a set of >> metadata that's created during the product build and placed on the >> Solaris media at $CDROOT/Solaris_<version>/Product/.pkghistory for the >> installer to consume. Suffice to say, the changes you're suggesting can >> be dealt with easily, as far as I can see. > > Great. I suppose there will be more visibility into this stuff once the > admin/install consolidation is opened? > Well... some of this stuff isn't necessarily part of any consolidation at this point; I know that RE wants to open up some of these tools and docs, which is why Rob Anderson wrote the proposal that got this community kicked off and is a co-lead for this community. I don't know where they stand on going further with those ideas - I do know they've been busy as can be with the various Nevada builds and S10 updates. One note on current consolidation structure: up through Solaris 10, it was the Admin/Install consolidation, but as of Nevada they were split into separate Admin and Install consolidations. My team owns the open-sourcing of Install, but somebody else has the problem for Admin. As a result, they'll each be happening on their own schedule (and no, I don't have a better date for Install yet than the "later this year" that's already out there). Dave
