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

[bugzilla-daemon at bugzilla.wpkg.org]

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

--- Comment #13 from Keith Jones <k.e.jones at brighton.ac.uk>  ---
(In reply to comment #11)
> 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.