[wpkg-users] [Bug 177] Local install flag
bugzilla-daemon at bugzilla.wpkg.org
bugzilla-daemon at bugzilla.wpkg.org
Mon Oct 5 12:16:11 CEST 2009
http://bugzilla.wpkg.org/show_bug.cgi?id=177
--- Comment #2 from Falko Trojahn <ftrojahn at smi-softmark.de> 2009-10-05 12:16:03 ---
Hello Rainer,
> Actually I am planning a feature like this for WPKG 1.2 release (I've got to
> find some time to continue development).
thanx for your quick reply, that's great.
> 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.
>
Don't think so.
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.
b) trying out package installation at a certain system which survives
a reboot would make really sense to me
> 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.
>
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 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
>
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.
> 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.
>
Yes, this would be a nice but additional feature.
> 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).
>
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?
>
> 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.
>
>
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.
I'd like to send a patch as proposal soon.
Best regards,
Falko
PS: Sorry if this posting is doubled, bugzilla didn't accept my reply per mail.
--
Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
More information about the wpkg-users
mailing list