> I never suggested that people should be able to "blow up" their systems with full root access.
We are both coming at this from different perspectives, so your example is installing Inkscape, and mine is installing Apache/Ruby/Haskell/GCC
Inkscape is a reasonably safe application to install because in the end the application either works or doesn't and what matters is the produced SVG file which is either compliant or non-compliant. I would have no objections to anyone installing that for one off interactive use.
Installing a web-server or a full-fledged programming language raises more concerns because it introduces something that has to be maintained into the future.
The problem is that the acceptability of applications is defined by the individual policy of the firm. Somehow the package manager has to classify packages in a manner that is consistent with the policy articulated by the firm, allowing the firm to then blacklist/whitelist individual packages as needed.
The problems are:
a) The semantics of any such configuration are unclear. If I blacklist X, but it is listed as a dependency of package Y which is in an allowed class... does that mean Y cannot be installed? What if it was a recommended dependency of Y and we have recommended packages turned on? What if Y was previously installed and a system upgrade moves X from recommended to required, does Y now need to be removed?
b) How granular is the classification to be? Are packagers really going to want to classify applications at the level of detail required by administrators trying to implement policy? Do they even know what administrators consider important? Do they agree?
c) Can any classification scheme possibly match policy? Policy might have more to do with use in practice than capability. Consider your Inkscape example. I might allow the occasional usage of Inkscape to create SVGs, but want to prohibit the scripting of Inkscape through python to automate the creation of charts for publishing. If Inkscape is white listed and python is a system dependency it may be impossible to express policy in a whitelist/blacklist at the package level, and some more conservative firms will then look at that and decide to blacklist everything.
d) Is policy defined or is it fuzzy? The firm may not know what to allow because they cannot anticipate all the crazy ways people might use the software they install. If the firm could actually articulate their policy clearly enough to implement as package management rules then the approval process would be much faster and might eliminate the need to even have this feature.