Jonathan Edwards wrote: > > On Nov 20, 2008, at 3:02 PM, Shawn Walker wrote: > >> Jonathan Edwards wrote: >>> On Nov 19, 2008, at 7:39 PM, Bart Smaalders wrote: >>>> Ed McKnight wrote: >>>>> Suggestion: IPS to implement a package attribute, 'metapackage=true,' >>>>> which would mean that the contained dependencies would be treated as >>>>> reversed during uninstall, thus enabling the dependencies both to be >>>>> automatically installed and uninstalled. Maybe there should be >>>>> enforcement that nothing other than dependencies are contained, >>>>> but I'm >>>>> not sure it's necessary. >>>>> >>>> We've talked about this; it's probably actually an attribute of the >>>> dependency or a different type of dependency rather than an attribute >>>> of the containing package. >>>> >>>> Some of this is waiting on our completion of capturing user intent, >>>> for the following reason: >>>> >>>> pkg install foo >>>> pkg install bar, which has a "meta-dependency" on foo >>>> pkg uninstall bar >>>> >>>> should not uninstall foo, whereas in the case of: >>>> >>>> pkg install bar, which has a "meta-dependency" on foo >>>> pkg uninstall bar >>>> >>>> it should... we cannot do this correctly w/o recording user intent. >>> how about something like: >>> pkg uninstall -r foo >> >> We already have -r. Are you saying it should change somehow, or are >> you suggesting that's what someone should use? >
Its easy to get this dependency backwards. A metapackage depends upon "content" packages (in the example below, metapackage bar depends upon foo). Installing bar brings along foo. Doing 'pkg uninstall -r bar' removes nothing except bar (unless there are packages installed that depend upon bar.) It will not remove foo. pkg uninstall -r bar will remove packages that depend upon bar, not those that bar depends upon. Since we find it convenient to install groups of packages via a handle like a meta-package (or "group package") it seems only logical to provide the same convenience for uninstall (and cruel not to :) I understand that a meta-package describing an operating system won't need to be removed very often, but the products that run under operating systems do have this need. If the packaging system doesn't provide it then the products have to invent it... If a product documents that it is to be installed/uninstalled by means of metapackages then intent is fully specified. No? thx, --emk > > okay - so if we have recursive uninstall, i'm not so sure i understand > what the particular problem is .. in other words, if we just view > metapackages (or i've always preferred metaclusters) as a top node > package that includes require dependent packages then i think you've > already got your mechanism for uninstalling clusters and forcing with > the recursive if the package wasn't installed as part of the > metacluster (perhaps a family tag to denote) > > and sorry - i was reading the above example backwards (late nights) .. > so in the above example you've really got a metacluster "bar" and > package "foo" which is part of the metacluster: > > case #1: > - pkg foo is already installed on the system > - you install metacluster bar > pkg uninstall bar <- won't uninstall foo > pkg uninstall -r bar <- will uninstall foo > > case #2: > - pkg foo is not installed on the system > - you install metacluster bar > pkg uninstall bar <- will uninstall foo as foo will have the > metacluster family tag > > use -n to flag warnings, and add a mechanism to add things or remove > things from family sets and i'd think you'd be all set. > > on a side note though - i would find it quite helpful to see some sort > of text visualization of indented clusters along with packages that > might be incorporated in the cluster .. and perhaps packages that > weren't installed as part of the cluster (or tagged as part of the > family .. in-laws if you will): > > - pkgcluster bar > [foo] > fu > fhoo > phoo > > --- > .je _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
