[wpkg-users] Definition change/Version #

[Sean Kennedy]

So I've been fiddling with wpkg over the past week, and I dig how versatile
it is while retaining it's simplicity.  It's the perfect fit for the
organization I work for.  However, in my testing I've kicked up a possible
problem;
As I build packages and deploy them, I've discovered errors within them.
 Naturally, I fix these errors, but if wpkg doesn't detect a version status
change ( either through the revision # on the package, nor it's internal
checks ), it doesn't copy the new package definition to it's local cache.
 Sitting here it occurs to me that I might just be able to increment the
revision number on the package, and it copies the new package information to
it's local cache.  If there are no upgrade commands, will the only action
taken be that of wpkg updating it's local cache of the package definition?
-
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
___
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users

Re: [wpkg-users] [Bug 175] Test return value of removeSettingsNode function

[simplesi]

Chris Wilcox wrote:
> 
> 
> I also use WPKG across 16 schools.  One of the first things I did when
> trialling and now using wpkg live was dredge out an old and unused PC
> capable of running XP Pro and set this up as a test workstation for wpkg
> packages before I roll things out to the live networks.
> 
:) 
I know all the workarounds - I'm trying to not have to do them as none are
the same as the real world :)

regards

Simon


-- 
View this message in context: 
http://www.nabble.com/-Bug-175--New%3A-Test-return-value-of-removeSettingsNode-function-tp25737803p25751042.html
Sent from the WPKG - Users mailing list archive at Nabble.com.

-
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
___
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users

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

[bugzilla-daemon]

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





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

...

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 

Re: [wpkg-users] wrapper settings path mismatch problem

[Falko Trojahn]

Marco Gaiarin schrieb:
> Mandi! Falko Trojahn
>   In chel di` si favelave...
>
>   
>> usually I do such upgrade things using a package, see attached.
>> 
>
> A little question: why use:
>
>   cmd /c start /min msiexec
>
> on install and simply only 'msiexec' on upgrade?
>
>
> I'm curious... ;)))
>
>   
Hmm. I mean to remember a time where we had the transition from
"wpkg_start.bat"-service to "WPKG Client"
and there was another package for removing the old service.
Perhaps this was a workaround for some timing issue ... don't know.
Perhaps this can be removed.

Falko

-
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
___
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users

Re: [wpkg-users] revision number problem

[Marco Gaiarin]

Mandi! Rainer Meier
  In chel di` si favelave...

> However this punctuation is very uncommon (I've never seen that before). I

I will use ':' just for it's 'strangness': well suited to mark and
'internal' subrevision number...


Many thanks.

-- 
dott. Marco Gaiarin GNUPG Key ID: 240A3D66
  Associazione ``La Nostra Famiglia''http://www.sv.lnf.it/
  Polo FVG  -  Via della Bontà, 7 - 33078  -  San Vito al Tagliamento (PN)
  marco.gaiarin(at)sv.lnf.it  tel +39-0434-842711  fax +39-0434-842797

Dona il 5 PER MILLE a LA NOSTRA FAMIGLIA!
   http://www.lanostrafamiglia.it/chi_siamo/5xmille.php
(cf 00307430132, categoria ONLUS oppure RICERCA SANITARIA)
-
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
___
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users

Re: [wpkg-users] wrapper settings path mismatch problem

[Marco Gaiarin]

Mandi! Falko Trojahn
  In chel di` si favelave...

> usually I do such upgrade things using a package, see attached.

A little question: why use:

cmd /c start /min msiexec

on install and simply only 'msiexec' on upgrade?


I'm curious... ;)))

-- 
dott. Marco Gaiarin GNUPG Key ID: 240A3D66
  Associazione ``La Nostra Famiglia''http://www.sv.lnf.it/
  Polo FVG  -  Via della Bontà, 7 - 33078  -  San Vito al Tagliamento (PN)
  marco.gaiarin(at)sv.lnf.it  tel +39-0434-842711  fax +39-0434-842797

Dona il 5 PER MILLE a LA NOSTRA FAMIGLIA!
   http://www.lanostrafamiglia.it/chi_siamo/5xmille.php
(cf 00307430132, categoria ONLUS oppure RICERCA SANITARIA)
-
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
___
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users

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

[bugzilla-daemon]

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





--- Comment #2 from Falko Trojahn   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.
-
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
___
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users

Re: [wpkg-users] wrapper settings path mismatch problem

[Falko Trojahn]

Hello Paul,
> Hi,
>   I need some help to try and rectify a problem, of my making!
> I manually edited the settings.xml to change from server1 to server2 but 
> missed the wrapper path and only changed the settings paths.
> Now I have the path for the wrapper \\server1\wpkg\wpkg.js and the 
> settings/software as \\server2\wpkg\settings.xml so wpkg fails.
> Has anyone got a suggestion on how to change these?
> Where are the wpkgservice settings stored? Registry? Xml file? As I could try 
> and change it via a DS group policy.
>   
usually I do such upgrade things using a package, see attached.

In your case I think it would make sense to role out a (computer) group
policy like e.g.
 %PROGRAMFILES%\WPKG\wpkginst.exe
--SETTINGSFILE=\\your-logon-server\netlogon\wpkg\settings.xml
to get things right again.

Good luck,
Falko



   

   

   
   


   
   
   
   
   
   



-
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
___
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users

Re: [wpkg-users] revision number problem

[Malte Starostik]

Hi Marco,

Am Montag, 5. Oktober 2009 11:27:15 schrieb Marco Gaiarin:
> Mandi! Rainer Meier
>   In chel di` si favelave...
> 
> > This is true as well and has been introduced quite recently by a heavy
> > improvement of the version comparison algorithm.
> 
> A little, probably unrelated question. There's a separator defined for
> 'internal subrevision'?
> EG, for now i use, for firefox:
> 
>   30141
> 
> for 3.0.14 internal revision 1; i use internal revision because i'm
> human and male, so i make mistakes ;), and when i do that, i can fix
> the packege augmenting only the internal revision.
> 
> Can i write now as:
> 
>   3.0.14:1
> 
> or whatever separator i like, : , ; , -, |, ... different from dot to
> mark them explicitly as 'internal revision'?

That should work, yes.  As a Gentoo Linux user, I'm used to internal revision 
numers like 3.0.14-r1 so that's what I'm using and it works, too.  Basically 
it's just a matter of personal preference, most choices will work correctly by 
virtue of WPKG's flexibility :-)

Cheers,
Malte
-
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
___
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users

Re: [wpkg-users] revision number problem

[Rainer Meier]

Hi Marco,

Marco Gaiarin wrote:
> A little, probably unrelated question. There's a separator defined for
> 'internal subrevision'?
> EG, for now i use, for firefox:
> 
>   30141
> 
> for 3.0.14 internal revision 1; i use internal revision because i'm
> human and male, so i make mistakes ;), and when i do that, i can fix
> the packege augmenting only the internal revision.
> 
> Can i write now as:
> 
>   3.0.14:1
> 
> or whatever separator i like, : , ; , -, |, ... different from dot to
> mark them explicitly as 'internal revision'?

Well as far as I remember the algorithm everything which is not a number can be
used as a separator (words, characters, punctuation marks)
So yes, a version number of 3.0.14:1 would be "allowed"
I think the evaluation would be as follows:
3.0.14 <-> 3.0.14:1 is newer
3.0.14:1 <-> 3.0.14:2 is newer
3.0.14:1 <-> 3.0.15 is newer
3.0.14:1 <-> 3.0.15:1 is newer

However this punctuation is very uncommon (I've never seen that before). I
suggest you to just add another period mark:

3.0.14.1

What I've seen some times is a "release marker":

3.0.14r1

which shouold be supported by the algorithm:
3.0.14r1 is newer than 3.0.14
3.0.14r2 is newer than 3.0.14r1
3.0.15 is newer than 3.0.14r50

But I would prefer the simple punctuated notation above:
3.0.14.#


If in doubt which result the version comparison evaluation yields just open the
debug log file and look for "Comparing version: 'x' <=> 'y'." entries.

br,
Rainer
-
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
___
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users

Re: [wpkg-users] Strange error...

[Rainer Meier]

Hi Marco,

Marco Gaiarin wrote:
> ...my first try, but the installer say: «you have just the latest
> version, thanks.». ;(((
> Seems there's no way to reinstall...

Maybe it checks some (existing) registry keys and then exits. ProcessMonitor
might help to detect the right entries, remove them and then re-install it. But
this is quite messy - especially since we should assume that WSH is installed
properly.


>> Which version of wpkg.js are you running?
> 
> 1.0.4 (i'm upgrading now) and on line 4252 there's:
> 
>   var tempLogPath = new 
> ActiveXObject("WScript.Shell").ExpandEnvironmentStrings("%TEMP%\\wpkg-logInit.log");

Upgrading to 1.1.2 is recommended. However the same functions are used in WPKG
1.1.2 too.
I guess it's somehow unable to locate "ExpandEnvironmentStrings" on the
"WScript.Shell" object. Why? No clue :-(


>> Try re-installing cscript and attach a full WPKG debug log (if it does not 
>> dash
>> out directly at startup before it writes anything).
> 
> ...seems that wpkg does not produce any output at all. ;(

Well, ExpandEnvironmentStrings is used to expand the location where the log file
is written. So no chance for WPKG to initiate the log part.

It's not the first time that something like this happens. I ought to remember
that a similar problem has been reported once but I think this guy just
re-installed the machine and the problem was gone.

Maybe you can trace execution with ProcessMonitor - see if it (cscript.exe)
tries to access some files which are missing (or registry entries). Just do it
if you have the patience to do so. Alternatively just re-install the machine.
If you're able to trace it down to the root cause we would be interested to hear
what was causing it.

br,
Rainer
-
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
___
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users

Re: [wpkg-users] revision number problem

[Marco Gaiarin]

Mandi! Rainer Meier
  In chel di` si favelave...

> This is true as well and has been introduced quite recently by a heavy
> improvement of the version comparison algorithm.

A little, probably unrelated question. There's a separator defined for
'internal subrevision'?
EG, for now i use, for firefox:

30141

for 3.0.14 internal revision 1; i use internal revision because i'm
human and male, so i make mistakes ;), and when i do that, i can fix
the packege augmenting only the internal revision.

Can i write now as:

3.0.14:1

or whatever separator i like, : , ; , -, |, ... different from dot to
mark them explicitly as 'internal revision'?


Thanks.

-- 
dott. Marco Gaiarin GNUPG Key ID: 240A3D66
  Associazione ``La Nostra Famiglia''http://www.sv.lnf.it/
  Polo FVG  -  Via della Bontà, 7 - 33078  -  San Vito al Tagliamento (PN)
  marco.gaiarin(at)sv.lnf.it  tel +39-0434-842711  fax +39-0434-842797

Dona il 5 PER MILLE a LA NOSTRA FAMIGLIA!
   http://www.lanostrafamiglia.it/chi_siamo/5xmille.php
(cf 00307430132, categoria ONLUS oppure RICERCA SANITARIA)
-
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
___
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users

Re: [wpkg-users] Strange error...

[Marco Gaiarin]

Mandi! Rainer Meier
  In chel di` si favelave...

> >  Microsoft (R) Windows Script Host Versione 5.7
> Seems to be the latest version. Maybe re-installing it
> ()
> could help. Just try.

...my first try, but the installer say: «you have just the latest
version, thanks.». ;(((
Seems there's no way to reinstall...


> Which version of wpkg.js are you running?

1.0.4 (i'm upgrading now) and on line 4252 there's:

var tempLogPath = new 
ActiveXObject("WScript.Shell").ExpandEnvironmentStrings("%TEMP%\\wpkg-logInit.log");


> Try re-installing cscript and attach a full WPKG debug log (if it does not 
> dash
> out directly at startup before it writes anything).

...seems that wpkg does not produce any output at all. ;(

-- 
dott. Marco Gaiarin GNUPG Key ID: 240A3D66
  Associazione ``La Nostra Famiglia''http://www.sv.lnf.it/
  Polo FVG  -  Via della Bontà, 7 - 33078  -  San Vito al Tagliamento (PN)
  marco.gaiarin(at)sv.lnf.it  tel +39-0434-842711  fax +39-0434-842797

Dona il 5 PER MILLE a LA NOSTRA FAMIGLIA!
   http://www.lanostrafamiglia.it/chi_siamo/5xmille.php
(cf 00307430132, categoria ONLUS oppure RICERCA SANITARIA)
-
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
___
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users

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

[bugzilla-daemon]

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


Rainer Meier  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED




--- Comment #1 from Rainer Meier   2009-10-05 11:10:11 ---
Hi Falko

Actually I am planning a feature like this for WPKG 1.2 release (I've got to
find some time to continue development).

However my idea of "how" was slightly different. It's very unlikely intended by
administrators to allow users to work with "outdated" software. So I thought
about allowing users to install packages manually (as long as they got
permissions to install software locally) and these packages are added to
wpkg.xml and starting from then regarded as a part of the profile. This would
allow users with appropriate permissions to "extend" their profile and add
packages from the repository provided while the software they add will be
automatically updated.
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.

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.

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

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. 

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).


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.

-- 
Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the QA contact for the bug.
-
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
___
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users

[wpkg-users] wrapper settings path mismatch problem

[Paul McGrath]

Hi,
  I need some help to try and rectify a problem, of my making!
I manually edited the settings.xml to change from server1 to server2 but missed 
the wrapper path and only changed the settings paths.
Now I have the path for the wrapper \\server1\wpkg\wpkg.js and the 
settings/software as \\server2\wpkg\settings.xml so wpkg fails.
Has anyone got a suggestion on how to change these?
Where are the wpkgservice settings stored? Registry? Xml file? As I could try 
and change it via a DS group policy.

BTW, thanks to everyone for the help on the downgrade version stuff, it worked 
great.


Thanks
Paul

--
Paul McGrath,
IT Manager,
Leeds Institute of Molecular Medicine,
St James's University Hospital,
Beckett Street, Leeds, LS9 7TF, UK
Ext.: Uni - 38630, NHS - (89)38630
Tel.: +44 113 34 38630
Email...: j.p.mcgr...@leeds.ac.uk
Homepage: http://www.limm.leeds.ac.uk




-
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
___
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users

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

[bugzilla-daemon]

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

   Summary: Local install flag
   Product: WPKG
   Version: 1.1.2
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: wpkg.js
AssignedTo: r.me...@wpkg.org
ReportedBy: ftroj...@smi-softmark.de
 QAContact: wpkg-users@lists.wpkg.org


Some time ago I missed the feature of packages marked as "locally installed",
which came to my mind again as a possible solution for bug 175,
so I'll try to explain that here.

Preference:
"wpkg.js /install:" does install a package locally, 
"wpkg.js /remove: does remove that same package.

Problem:
But wpkg.js /synchronize does - logically - remove all packages which
are not in hosts/profiles database. So, locally installed packages are
automagically removed from the system as intended.

Sometimes, e.g. for testing reasons or to give a special user the possibility
to install a package himself, I think it would be essential to have a manually
installed package not automagically removed from the system when synchronizing.

Solution:

"wpkg.js /install: /local" or
"wpkg.js /install: /persistent"

marks a package in local wpkg.xml as
 ... 

or

 ... 

For the difference between "local" and "persistent" I could imagine that
for "local" packages the usual upgrade mechanism of wpkg.js /synchronize
is used, but "persistent" packages never upgrade automagically, so I can
have a system with a special revision of a package until I upgrade this
system manually or the package is assigned to this host by
hosts.xml/profiles.xml.

Keep up with your good work!
Regards,
Falko

-- 
Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the QA contact for the bug.
-
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
___
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users

[wpkg-users] [Bug 176] WPKG Service crashes when using Offline mode

[bugzilla-daemon]

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


Marco Gaiarin  changed:

   What|Removed |Added

 CC||g...@sv.lnf.it




--- Comment #1 from Marco Gaiarin   2009-10-05 10:00:42 ---
I can absolutly confirm that. Same error.
Windows XP sp3 fresh updated.

I've noted also that if i disable offline mode WPKGClient works, but the
process remains in a spurious state, eg i've to kill WPKGSrv.exe process to be
able to restart it.

Also in my organization i use mainly the 'oldstable' 1.2.1 version, and on some
poratble system the 'beta' 1.3.6 with no trouble at all.

-- 
Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the QA contact for the bug.
-
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
___
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users

Re: [wpkg-users] [Bug 175] Test return value of removeSettingsNode function

[Chris Wilcox]

> 
> 
> Starting from the beginning again :)
> 
> I adminster several small school networks and use wpkg to deploy packages to
> several machines if it is quicker to use wpkg than to go around all
> computers and do a manual install.
> 
> I want to be able to test a new package out or a modified one on an existing
> live system.
> 
> I do this by trying to allocate/modify a package on one computer.
> 
> In practice, I have found this difficult to achieve this cleanly without
> breaking something sometimes :(
> 
> Currently, WPKG will remove a package entry from WPKG.xml if it decides that
> the package is no longer required for that computer.
> 
> Even with the two exisiting flags (noremove and noforced remove) WPKG will
> still remove the package entry from WPKG.xml under certain circumstances.
> 
> If a mistake is made, and then later rectified, then WPKG thinks it hasn't
> installed a package and attempts re-install.
> 
> IF I programmed a package with checks - I could probably work around this
> but I don't. I don't use checks and I dont use remove commands. I just have
> an install command to install and an update command to update -very simple
> :)
> 
> If I could have a flag to stop WPKG from removing package entries, then when
> my mistake is rectified, wpkg would not attempt a re-install.
> 
> Its that simple :)
> 
> I don't use WPKG to keep track of everything on my network - I just use it
> if it might save me time and effort.
> 
> Obviously if I had a separate testing setup, virtual/real testing machines
> or didn't make mistooks then I wouldn't have a problem - but I dont have
> these and therefore I have a problem :)
> 
> regards
> 
> Simon
> PS
> Just for reference my basic code change proposal is
> 
> function removeSettingsNodeSW(packageNode, saveImmediately) {
> // sw modified to stop removal if no remove instructions found
> if (getPackageCmdRemove(packageNode).length > 0) {
> // make sure the settigngs node is selected
> var packageID = getPackageID(packageNode);
> dinfo("Removing package id '" + packageID + "' from settings.");
> var settingsNode = getSettingNode(packageID);
> var success = false;
> if(settingsNode != null) {
> success = removeNode(getSettings(), settingsNode);
> }
> // save settings if remove was successful
> if (success && saveImmediately) {
> saveSettings();
> }
> return success;
> } else {
> var packageID = getPackageID(packageNode);
> dinfo("package id '" + packageID + "' not removed as no remove
> instructions found.");
> var success = false;
> return success;
> }
> 
> }
> 
> and then the calling code should check the return success value

 

I also use WPKG across 16 schools.  One of the first things I did when 
trialling and now using wpkg live was dredge out an old and unused PC capable 
of running XP Pro and set this up as a test workstation for wpkg packages 
before I roll things out to the live networks.

 

If you don't ever want wpkg to remove an entry from the local wpkg.xml file 
then just leave the entry in the profile.xml.
  
_
View your other email accounts from your Hotmail inbox. Add them now.
http://clk.atdmt.com/UKM/go/167688463/direct/01/-
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
___
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users