http://bugzilla.wpkg.org/show_bug.cgi?id=177 Rainer Meier <r.meier at wpkg.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #1 from Rainer Meier <r.meier at wpkg.org> 2009-10-05 11:10:11 --- Hi Falko Actually I am planning a feature like this for WPKG 1.2 release (I've got to find some time to continue development). However my idea of "how" was slightly different. It's very unlikely intended by administrators to allow users to work with "outdated" software. So I thought about allowing users to install packages manually (as long as they got permissions to install software locally) and these packages are added to wpkg.xml and starting from then regarded as a part of the profile. This would allow users with appropriate permissions to "extend" their profile and add packages from the repository provided while the software they add will be automatically updated. Adding an application via WPKG and having it installed as a "one shot" installation does not require WPKG - users could simply install the application manually without WPKG knowing about it. However this change also includes some more changes in existing algorithms. For example if the administrator then decides to add a package to the profile assigned to the node which has been manually added by the user before - so the package should "transfer" from a user-added package to a profile-managed package. I don't think a switch like "/local" and/or "/persistent" is required in this case since every package added by the user will be maintained from this point in time by WPKG. So if a user adds a package manually it will also be upgraded if the administrator adds a new version I think another configuration parameter to reset client configurations (and a command-line switch) would be required. This would allow administrators to re-enforce the installation of only the packages in the profile - ie. all "local" packages are removed. Unfortunately this drives WPKG into a direction which requires to include much more mechanisms. Soon we would have requests to allow/disallow "local" packages on profile level (on some hosts they are allowed, on some they are not). I am not sure this makes sense to manage in WPKG because it would require users to have software-installation privileges for WPKG and no privileges for the user to install software manuelly in order to make any sense (else users could anyway install the software without invoking WPKG). Finally I can say that this is certainly more demanding to implement than it might look at the beginning and it's certainly not a feature/change to be implemented within the current stable release. However we keep this report open and queue it as an enhancement for future releases. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. |