James Carlson wrote: > Mike Shapiro writes: >> b. A mechanism for asking the question "what happens if I remove you?" >> i.e. for asking for confirmation. >> >> The current package system has no interface to permit (b) -- i.e. to call >> into something in the package or intrinsically understand that. This is >> an example of where you want a separation between the internals and >> a particular presentation layer where it may or may not be appropriate >> to pop up some dialog box and say "this is running -- are you sure >> you want to remove it?" Clearly if nothing else decide the answer for IPS, >> since we certainly won't go back and address this in legacy packaging.
My first thought on this was to ask the IPS folks whether actions will (or already do) participate in dry-run mode (install/uninstall -n). I'd think they should. If they do, it'd just be a matter of factoring the results so that various presentation layers could consume them. > > It's unclear to me which of these two things (package and service > names) is really intended to be the primary administrative unit. As long as there are packages without services (i.e. forever), packages will remain as a primary administrative unit. So, I think we'd be discussing additional features in the packaging system rather than a fundamental change in primary administrative unit. I don't currently think that having the svc* commands grow IPS knowledge would be the right architecture either. (Though am not suggesting that's what you were proposing.) > The text above seems to be written as though the package name is that > unit: we'd want to ask "what service is (or services are) damaged if > this package is removed?" > > Wouldn't it be somewhat more consistent to deal just in FMRIs, since > that's how the rest of the system is managed? That is, I'd like to be > able to say "please remove svc:/network/foobar and whatever horse it > rode in on," rather than trying to divine sets of package names by > looking at services. Better still, I'd like to install by service > name. It might be a nice feature, and something to take up with the new packaging system. It seems best discussed there as I'd quickly ask why I couldn't install by filename too. e.g. I want mutt; why do I have to pkg search, then pkg install? The two problems seem at least related. (Disambiguation is even the same: a fully qualified FMRI or fully qualified pathname should have a unique package mapping in an IPS repository. An abbreviated or partial one may not.) (I believe you'll be able to search by fmri by the time they're done, but I've lost track of whether I just dreamed it and if not, whether it's still part of the plan.) Since we seem to have diverged from the original question to features of pkg, I've included pkg-discuss. We may wish to consider a wholesale move over there, but I'm crossposting for now. liane
