Nicolas Williams wrote: > 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. >
Actually, I'm not sure it really matters now that I think about it. I think the way you'd want to do this is to have three new types of entries in the pkgmap: - abandon (I'm dropping this file, but some other package is picking it up, so leave it in place, just remove my reference to it in contents) - adopt (the other half of the above) - delete (remove the file) The abandon/adopt doesn't have to happen in one transaction (which is probably easier to implement in pkgadd anyway). Dave
