[wpkg-users] [Bug 121] additional EXCLUDES node for profiles

[bugzilla-daemon at bugzilla.wpkg.org]

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.