http://bugzilla.wpkg.org/show_bug.cgi?id=121 --- Comment #2 from Evan Sebenius <sebene at u.washington.edu> 2008-05-29 00:28:26 --- Thank you for the very quick reply. I've read what you've posted, and have a few comments in response: Regarding package dependencies, this update as presented will affect their being added to the list. The "getProfilePackageNodes()" function does take into account package dependencies. However, some modifications would allow for the exclusion to apply before package dependencies are analyzed. This would let a package be excluded before the packages it depends on are included (resolving dependent packages installed for no reason) and would be overridden in the event that an excluded package is depended upon by another package. An exclusion principle formed in this way would only ignore packages as if they never appeared on the profile list. If they appear somewhere within the package dependency tree, they will effectively ignore an exclusion. Due to this, packages that depend on other packages will have exactly the necessary additional packages installed, and no extra packages will be installed. It seems that properly formed packages that depend on other packages will use package dependencies, rather than profile dependencies. If all dependent packages are well-formed, then package exclusion or blacklisting will not affect the integrity of their dependencies. It seems like the largest complaint against the ability to exclude a package is that package dependency will be compromised. I am able to update my patch (it would even be more efficient) to retain the integrity of package dependency, and if you approve of adding it to wpkg.js, I am more than willing to update my patch and test it thoroughly with a test scenario of all sorts of dependencies. As for the reasons for using such an option, I feel that there are wpkg environments that could benefit from this option, and that the other options are less optimal. Consider a research lab with a hundred researchers: There is a basic set of software, set up in a sensible profile tree, including a variety of analysis programs, standard web applications, office apps, etc. One of these applications is Adobe Reader. We have a site license for Adobe Standard, allowing installations on a per-need basis. We would like to automate this through wpkg rather than manually servicing every machine that has this software. Since Adobe Reader is deep within the profile tree, it would require a very large, arbitrary profile to encapsulate all software that would normally apply to that profile except for Reader. Possible, yes, to do this for just one package, but you've lost all use of the profile tree in this instance. In addition, if there are 20 workstations with Reader, then if there is an update inside the profile tree, that update must also be added to each of these 20 user-specific profiles. Thus, keeping individual profiles for excluding packages deep within the profile tree is sub-optimal. Also, it is not possible to determine which machine should or should not have Reader based on anything specific to that machine (processor speed, OS, etc). The use, then, for the excludes functionality is that instead of building a massive, profile-tree-blind profile for each user that shouldn't have Reader, would be to assign them the same basic profile as their peers except with Reader excluded, and Standard included. Were this the only situation, or if all situations could be pre-determined, I would agree that making a top-level package choice for individual users with/without Reader would make perfect sense. However, when faculty and researchers are constantly circulating, it is very likely that another package deep within the tree will need to be removed for one (or a group of) user(s), requiring additional reworking of the profile structure every time new software like this is required. Finally, I'd like to note that with multiple administrators, there can always be confusion if communication is lax. However, since the exclude function includes verbose debug messaging, it would be easy to spot when searching the debug log for the package name that is causing a problem, just as it would be to search for a package whose commands are buggy or missing. I'll admit Exclusion is not a feature that we "cannot live without," although I might argue that package-level dependencies and date-specific installations are of a similar caliber of rather useful addition. Exclude would be a feature that would have to be used responsibly, just as ip-based installation or packages that 'execute="always"'. In conclusion, a modified version of the patch I submitted will only take into account profile exclusions, and will go into effect before package-level dependencies are considered. Thus, it will not violate compatibility within well-formed profile/package trees, and has general applicability to environments that include the need to exclude specific elements of packages deeply-nested in the profile tree without compromising the integrity of the tree itself. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. |