Ethan Quach wrote: > > > Enda O'Connor ( Sun Micro Systems Ireland) wrote: > >> James Carlson wrote: >> >>> Enda O'Connor ( Sun Micro Systems Ireland) writes: >>> >>>> I was not aware of this particular mess. For now I'm not too >>>> convinced of how to fix this in the short term ( at least S10 time >>>> anyway ), ie customers applying patches such as the KU to their >>>> miniroot. >>>> I guess we could include some rev of SUNWsibi, but this is ugly and >>>> as SUNWsibi is different from FCS to 1/06 and again in U3, not clear >>>> what implications this would have. >>> >>> >>> >>> >>> I agree; it's not clear. We could add SUNWsibi to the releases >>> (putting it somewhere convenient, such as Solaris_10/Tools/SUNWsibi), >>> and include README notes for those patching the miniroot that >>> describes how to use it. >>> >>> An alternative might be to have a special form of the original patch >>> -- intended for miniroot use only -- that merely has those 'special' >>> files excised. >>> >>> Both have risks, and it'd be good to limit the amount of time we do >>> something like that. >>> >>> >>>> I suggest a bug/RFE to cover the whole implementation of SUNWsibi to >>>> cover the wider picture, I can log that, but we need to agree some >>>> short term fix/hack for now as well. ( either that or not miniroot >>>> patching for KU's, which is not good ) >>> >>> >>> >>> >>> Thanks for logging the bug. ;-} >>> >> >> I have logged RFE >> 6478159 Use of SUNWsibi in the build process for the miniroot breaks >> patching of miniroot via patchadd -C > > > I don't think sibi is the only culprit. The inability to use patchadd > -C to patch arbitrary patches to the miniroot is a result of it never > being designed to do so, not because anything broke it. I think this > RFE should read "Need a way to patch abitrary patches to the miniroot" > because sibi is not the only *special* step in the miniroot build > process. There's also the step of removing a ton of unneeded files from > the miniroot to save space. The list is owned by the Install > consolidation, and RE uses it when building images. Applying arbitrary > patches on top of the miniroot would undoubtly reintroduce some of these > files, which is a breakage that has nothing to do with SUNWsibi at all. > As I am not familar with the miniroot build process per se ( SUNWsibi was news to me ), I'm not in a position to comment as such on the brokeness of the miniroot build process.
But I do know that customers ( and this thread is from a customer ) patch miniroot's, in order to gain driver support and so on. Now in S10 the files that SUNWsibi delivers that conflict with genric patchehs all appear to be svc related, for boot purposes, in S9 and earlier I suspect that somehow these conflicts did not arrise. I do know from experience that customers have experienced a range of issues patching miniroot's in S10 ( I can look for the bugs if needed ). Now that is not to say the patchadd -C worked flawlessly in s9 and earlier ( clearly not from doing a bugtraq search ). But this appears to be a new issues as such, that SUNWsibi is delivering files that conflict with generic patches in S10. Either that or SUNWsibi conflicts in s9 and earlier just did not get noticed, and so therfore were probably benign to some degree. Enda > > As a side thought, why is this all of the sudden a huge problem now? > (And I'm asking just to know why, not to argue that we shouldn't fix > anything.) The miniroot's special files, its build process, and > patchadd -C have been pretty constant since Solaris 8 or earlier, so I'm > just curious. Is it just that customers' needs are changing? If so, > its unfortunate we weren't able to capture this requirement ahead of > time before something just seemingly broke. > > > -ethan > > > >> >> Please feel free to update as appropiate >> >> This RFE is more for the long term goal of fixing miniroot build >> process with respect to SUNWsibi. >> >> Still to agree some sort of fix for short term ie >> 1 Infodoc with downlaod instructions for SUNWsibi appropriate to >> release, and instructions for install of same etc. >> 2 Some hackery in the affected patches to re-apply no-op versions of >> the files, via postpatch and pkgcond etc, not looking attractive to me >> at any rate:-) >> >> I'm tending to go with 1 as this point? >> >> Enda >> _______________________________________________ >> install-discuss mailing list >> install-discuss at opensolaris.org >> http://opensolaris.org/mailman/listinfo/install-discuss > > _______________________________________________ > install-discuss mailing list > install-discuss at opensolaris.org > http://opensolaris.org/mailman/listinfo/install-discuss
