James Carlson wrote: > Darren J Moffat writes: >>> It'd be possible, I think, to use this strategy _only_ for the S10 >>> backport. >> Actually that scares me even more, moving a file from one package to >> another in an update release. Eek! > > Why? That's exactly what the original discussion was all about.
I just have a gut feeling that this is going to cause patch problems. By that I mean problems for the people that create patches and build them not installation of patches. I hope I'm wrong! > reason they're considering moving files around at all is that the > current package attributes make the package hollow (not delivered in > non-global zones), the project wants to deliver in a patch, and that > can't be changed in a patch. Yep I follow that. It just also feels strange that for an S10 update files would get moved to a non hollow package but if it wasn't for the update the package would just be come full rather than hollow. I so wish we didn't do Solaris updates from patches! >> So if for some reason the IPfilter packages weren't installed, after >> this change there would be IPfilter files appearing because some core >> pacakge was installed or patched. Eek. This type of thing scares some >> people (even if it shouldn't it does). > > As long as the actual code dependencies work out right, I don't see > what the concern here might be. I agree but it does seem strange to move files out of a component specific package in to a generic core Solaris package because of the way that patching works. > If they don't, then it's a new, separate package. Which has its own issues in patching :-) Maybe it is better I go back into my hole until a proposal actually comes forward and I can see something concrete rather than making guesses. ta -- Darren J Moffat
