On Fri, Feb 16, 2007 at 06:04:09PM -0500, Dave Miner wrote: > Nicolas Williams wrote: > >Actually, there might be a better way to deal with file moves across > >pkgs: add a new prototype(4) "file type" that indicates that the given > >file has moved to a different pkg or has been deleted altogether. This > >wouldn't tell the user what pkg it has moved to... > > Your suggested usage of prototype(4) might be a useful mechanism to > replace the pkghistory stuff currently used, but I think you'd need to > carry it through into the pkgmap to actually make it work as part of the > package operations.
I certainly meant for that to be the case -- this info being needed at pkg install time and prototype(4) being used only at pkg build time I don't see what else I could have meant :) > >Even better: ...but if we limit ourselves to moving files across pkgs at > >micro (update) or minor release boundaries then we can make sure that > >all related pkgs are available to the upgrade/install system and this > >issue goes away completely. > > Introducing such a limitation so long as we have the current Solaris > release model seems pretty difficult, since we're overloading projects > into patches via the updates. I just realized that when we move files across pkgs at patch releases we probably have the source and destination patch packages in the same patch. So no such limitation would be needed under any circumstance other than manual pkg updating, which we don't support for WOS pkgs. So we wouldn't need this limiation at all! Leaving an entry in prototype(4)/pkgmap(4) to tell the pkg system about files that have moved to other pkgs (without naming them, so we don't have to keep this up to date) should suffice in all circumstances. Then pkgadd(1M) would scan the pkgs it's installing for files that have moved out of them to make sure that each such file either a) is known in the contents file to have moved to some other pkg (or is not installed at all) or b) that one of the pkgs being installed/updated has a pkgmap entry for that file. > Anyway, we'll be working on the specifics of how we do install and > upgrade under Caiman over the next couple of weeks and I'll make sure we > consider this issue. Please do. Nico --
