Catching up on a few things... Nicolas Williams wrote: > On Thu, Feb 08, 2007 at 05:02:21PM -0600, Nicolas Williams wrote: >> On Thu, Feb 08, 2007 at 02:58:16PM -0800, David Powell wrote: >>>> This is what pkg dependencies are for -- extend that to add versions and >>>> to tell pkgadd that these have to be upgraded together. >>> Dependencies usually represent the functional needs of the software >>> delivered in them. Using/relying on a dependency to indicate that >>> file F moved from package A to package B between revs 3.1 and 3.2 >>> also seems semantically wrong (since there might not be an actual >>> functional dependency between the packages in either 3.1 or 3.2), not >>> to mention very difficult to maintain. >> We'll need a way to deal with files moving from pkg to pkg if we'd use >> pkg updating. The details can be worked out, but, yes, it would be a >> pain to manage that kind of metadata. And that's a good point in favor >> of pkgrm + pkgadd. >
I agree with Dave that using dependencies for this sort of thing feels wrong. I also think that figuring out how to discover and maintain dependencies is probably hard enough without burdening it with this issue, too. > 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. > 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. 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. Dave
