[wpkg-users] [Bug 177] Local install flag

[bugzilla-daemon at bugzilla.wpkg.org]

http://bugzilla.wpkg.org/show_bug.cgi?id=177





--- Comment #3 from Rainer Meier <r.meier at 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.