http://bugzilla.wpkg.org/show_bug.cgi?id=177
--- Comment #3 from Rainer Meier <r.me...@wpkg.org> 2009-10-05 13:13:59 --- > a) If the user has no right to install applications manually, but he can > queue an installation via e.g. a tool similar to wpkginst where he > has a choice of applications for installation, this would make sense. True. Such a tool would have to be developed first. I think it would require a WPKG-installer service running with correct privileges and a "user-GUI" which allows to send commands like "install package x" to the service which uses WPKG to install it. > b) trying out package installation at a certain system which survives > a reboot would make really sense to me Well, I thought my reply was clear. I _am_ actually planning that these packages installed manually (which do not belong to the profile) survive the next synchronization. I even think these packages should be handled and upgrade by WPKG from that point in time - just like any other package assigned by the administrator. > That's why my differentiation between "local" and "persistent" flags. > But you are right, perhaps we have to control by hosts/profiles if a > host may > or may not install persistent packages locally. I am quite sure some additional permission management would have to be introduced. But for the beginning I target only a simple implementation where users could add packages manually which stay on the host (persistently) and are updated by synchronization. Everything else might be added when we have some client-side management tool available. For the time being you would anyway need administrator privileges to use WPKG directly. The advantage at the beginning would be that local admins could install the package from the repository instead of installing it manually from a downloaded file - and it would be updated by the administrator of WPKG. > No. At the moment, if there is no additional flag in wpkg.xml for this > package, and the synchronization runs, this package is just uninstalled, > because it is not assigned to this host by hosts/profiles.xml. Yes, this is the _current_ implementation. But I have to modify it anyway to insert another attribute to the package when it's added to the local wpkg.xml. Just as a reminder for WPKG that this package has been manually added and should be maintained in addition to the packages in the profile. I just think we don't need an additional command-line switch for this. Packages which are added manually by using WPKG /install switch can be maintained by WPKG starting from the install date. > See my note above. And _if_ a user has the right to install software, > why shouldn't he use the wpkg mechanism but do it on its own? The advantage of WPKG is clearly to keep the installed packages up-to-date by automatic synchronization and roll-out by a central package manager. However only a few users know about this and even fewer will care about. The average user which has admin privileges just installs the same way as he/she is doing on the home computer - just download and install. So the way to go would for sure be to disallow users to install any software and provide a tool which allows to select any available software from the WPKG repository and apply it. WPKG will install it and the WPKG administrator will maintain it and provide updates. If a user needs a software which is not in the WPKG repository the user needs to contact the administrator ro provide it. Actually this would be possible already today. I don't know if it could be included in WPKGExrpess but it could provide a user-login for all users and provide access to define the profile for the host from which WPKGExpress is accessed. This would allow users to configure a custom profile for the host they are working on. Even without requiring any modification in WPKG. > Yes and no. I think that a "local" or "persistent" flag in wpkg.xml > would prevent manually installed packages from being removed by > synchronization and could be easily implemented - could even help > regarding Simon's bug 175 requirements. For sure it needs at least one additional attribute which flags that the package has been added manually and should be maintained by WPKG. I was mainly saying that I think we don't need additional /local or /persistent flags which bloats the user interface and packages installed by users using the /install flag should always be persistent (if the user just needs it for one session he could remove it afterwards). The same applies to the /local flag. If /install is used manually the package is anyway a "local" package. So I think only only one attribute in the package is needed... <package id='Firefox' name='Mozilla Firefox' revision='3.5.0' priority='50' reboot='false' local='true'> ... So WPKG just sets local=true for all packages installed via /install which are not part of the profile yet. All local=true packages are not removed during synchronization but are updated instead exactly like packages in the profile. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. ------------------------------------------------------------------------- wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/ _______________________________________________ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users