[wpkg-users] [Bug 273] Per user install support

[bugzilla-daemon at bugzilla.wpkg.org]

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

--- Comment #3 from Rainer Meier <r.meier at wpkg.org>  ---
> I know :-) ...but from my lazy point of view, a switch and a bit of extra code
> could do all those changes for me in a consistent documented way ;-)

And especially the documentation is one of the items I would be afraid of. It
would be hard to explain why WPKG uses username as hostname when the
/context:user switch is used. But if the user on purpose adds /host:%USERNAME%
then it's clear that he just want to enforce WPKG to use the username as host
name string. I mean it's not hidden in some program code but obviously stated
at the command line.

In general I am very concerned about such a change introducing issues and
pretty "obscure" concepts for a use-case where WPKG was not intended to be
used. To state it clearly, WPKG from my point of view is a tool for system
administrators to maintain system-wide settings. There are other mechanisms
like policies, ActiveSetup, Logon-Scripts etc. which are designed to target
enforcing user settings.

Obviously WPKG can also be used in such environment already using special
configuration. But honestly I don't feel like we should document and support
this use case officially as it's clearly very limited use-case and requires
extremely careful package definition and WPKG configuration to work properly.





>  As you say, it can all be done with different config file settings and
> different instances of WPKG. Having WPKG do it for me though... well, it'd be
> another magical moment where WPKG saves the day :-)

Even if WPKG would implement such a context switch it would still require to
independent instances. Unless we just duplicate the configuration parameters
and allow then to be defined independently. For example the location of
wpkg.xml would have to be configurable in config.xml as well (unless it's
hardcoded to %AppData% in user context, but this is something I really wouldn't
recommend).




> For Host matching;

>  a) Group matching uses a hardcoded $ to retrieve groups the machine is a
> member of so it'll never retrieve groups a user is a member of.
>  b) Some matches could be skipped (IP matching etc)
>  c) People would have to be careful about wildcard matches, particularly where
> they've used "*" as a catch-all match. A separate equivalent to HOSTS.XML file
> could be important. (handling this might not be trivial)


I guess this all refers to extended host attribute matching. In a) I guess you
refer to group membership checks which should apply then to the local user
rather than the machine. One could also use a simple cmd script to check for
user group membership and use "execute" type checks rather than extended host
matching.

For b) I can only say that IP matching and also other host attribute matching
is only performed if such checks/matches are used in packages. So we don't gain
anything if we disable these checks globally.

Not sure about c). The matching in hosts.xml and profiles.xml would be the same
as for hosts if the username is used as hostname. Moreover if you use the
/profile switch then this is ignored and WPKG selects a profile directly.



> For general issues;
>  b) *Some* extremely badly designed installers still write to
> HKCU\Software\Microsoft\Windows\Current Version\Uninstall when they do a
> per-user install. Perhaps the ScanKeys could do with adding HKCU to the search?

I think I have disabled this mainly due to performance issues. Scanning the
HKCU keys adds performance penalty. However in user-mode of course you might
want to check for uninstall entries. But you can still do this using a very
simple registry existence check.



>  Those "issues" (and I'm using the phrase very loosely, they're not issues with
> WPKG's core use) would benefit from having a little more code and a
> corresponding setting to switch them on and off.

And this is the key point here I guess. The use of WPKG in userspace is not
intentional even if it might work already very well. Officially supporting this
use (or even encourage it) would require all features to be tested in another
completely different environment. I doubt that the amount of installations
using WPKG in userspace justify this additional complexity and test effort.
Especially since WPKG even with the current features set is able to deal with
all use-cases I can think about right now. Maybe you have a concrete use case
which does not work in userspace with the current implementation.

Up to now I just see a big source for confusion in special user-context mode
and added test/development effort for the purpose of supporting an environment
which is perhaps better maintained using different technology like Group
Policies or ActiveSetup.
The use of WPKG in userspace is very, very limited:
- System administrators do not want to maintain software
  (core purpose of WPKG) in userspace
- System admins would rather use Group Policies or ActiveSetup to enforce user
settings
  (no WPKG needed here)
  Moreover WPKG can be very well used to maintain ActiveSetup configuration on
hosts

If a system admin still wants to use WPKG to maintain user-space software, then
this is already possible (ie not actively prevented) by WPKG. Although the
system admin would anyway have to be extremely careful about package creation
on userspace packages.



> If you think of it that way, a /context:"user|machine" switch does seem to add
> value to WPKG :-)

Your explanations do make sense, but you have not been able to convince me yet
that such a setup needs specific handling by WPKG. Also in the future I do not
plan encouraging admins to maintain userspace settings/software using WPKG
since this is a very fragile task and I believe it's usually leading to some
mess, either with or without the /context switch.

-- 
Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.