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

[bugzilla-daemon at bugzilla.wpkg.org]

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

--- Comment #11 from Rainer Meier <r.meier at wpkg.org>  ---
Hi Keith,

I will have to go through all these comments in a bit more detail. But
currently the summary to me really looks as follows:

No matter if a context switch for user|machine would be implemented you would
be strongly advised to set up an independent instance of WPKG with an
independent package/profile/configuration structure due to a couple of reasons:

- access permissions to the user-space WPKG shares and definitions are likely
  different from access-rights to the software repository
- WPKG in user-mode should also allow configure where wpkg.xml is stored and
how
  it's named, so an independent config.xml should be used
- Also logging configuration would require some adaptation in config.xml

- Defining user-space and machine-space packages in one single WPKG database
  (packages.xml) would technically be possible but I would strongly recommend
  to separate it


As already pointed out by Stefan you could set up a WPKG instance to perfectly
work with username-based profile assignment using conditional host/profile
definition. Matching by environment variable USERNAME perfectly works from
within WPKG and would allow you to do the same as I have outlined it using the
/host:%USERNAME% launch switch. So if you don't like command-line switches,
then just filter "in code" which means using conditional expressions.


As said above I would really strongly recommend to keep user-space packages
defined in an independent instance of WPKG and not mix machine and user
packages in packages.xml. If you're running an independent instance you will
also have independent config.xml files (one for machine-instance another for
user-instance on a different share). In each config.xml you can define the name
and location of the local wpkg.xml differently.

You have also asked whether a missing "hostname" conditional attribute equals
to hostname="*" somehow. Actually WPKG only filters for values which are
existing. So if you omit the hostname attribute, then WPKG will not filter for
it. Therefore you're right, if you omit hostname, then this means the condition
does not depend on hostname at all. WPKG internally just matches all the
attributes in the condition and if one of them does not match, then it entirely
ignores the statement in which the condition appears. So if you add a condition
to a host definition and one of the conditions do not match, then for WPKG it
looks internally like this host definition is not in the file at all (removed
from internal structures before processing).


So for me still it feels like you can easily use the full power of WPKG in
user-space even without any change. The only two items where I see improvement
are:

- Scanning of HKCU uninstall keys
- Query group membership of executing user rather than machine

The first one could be enabled/disabled by a config.xml switch. Or (more
preferrable to me) not even introducing a switch and just scan this key in
addition to machine uninstall keys. WPKG implements some new caching mechanisms
for uninstall keys which might not have a big impact any more. Alternatively
you can use simple registry checks already right now.

The second one will have to be evaluated. I would like not to mix the current
group matching (machine group matching) and a user matching. Maybe a simple
additional conditional-check attribute like "usergroup" could match for user
groups rather than machine groups. So one could even combine user and machine
group membership filters.

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