[wpkg-users] Manual package dependencies being uninstalled on sync

[Steve Kersley]

I'm not sure if there is a bug in the way that manual package installation is handled (unless it's by design?), or more likely I have made a mistake in my package? A packages installed as a dependency to a package that is installed manually wants to uninstall itself again on next synchronization.

For instance: I have a package, vc-runtime-2005, to install the MS VC++ runtimes which depends on both the x86 and x64 packages (I felt it was more elegant to do it this way than one package which contains combined checks for both architectures, if applicable, and installed both if either check fails):

[Originally the check, install, remove and upgrade statements weren't here - I added these to ensure that the problem wasn't being caused by wpkg not being able to tell if this parent package had installed successfully, see final paragraph below]

<package id="vc-runtime-2005" name="Visual C++ 2005 Runtime" revision="8" reboot="false" priority="10">
                <depends package-id="vc-runtime-2005-x86" />
                <depends package-id="vc-runtime-2005-x64" architecture="x64" />
                <check type="file" condition="exists" path="%CommonProgramFiles%\wpkg-meta\vc-runtime-2005" />
                <install cmd='%COMSPEC% /c mkdir "%CommonProgramFiles%\wpkg-meta\vc-runtime-2005"' />
                <remove cmd='%COMSPEC% /c rmdir /S /Q "%CommonProgramFiles%\wpkg-meta\vc-runtime-2005"' />
                <upgrade include="install" />
</package>

The child packages then contain their own check and install/upgrade/remove statements just for the one architecture.


With this example, if I install the vc-runtime-2005-x86 manually from the command line it stays installed.  However, if I install just the vc-runtime-2005 'parent' package, the packages install properly and succeed the post-install checks.  They show up in /query:i as installed:

Visual C++ 2005 Runtime
    ID:                vc-runtime-2005
    Revision:          8
    Reboot:            false
    Execute:           -
    Priority:          10
    Status:            Installed

Visual C++ 2005 Runtime (x64)
    ID:                vc-runtime-2005-x64
    Revision:          4
    Reboot:            false
    Execute:           -
    Priority:          10
    Status:            Installed

Visual C++ 2005 Runtime (x86)
    ID:                vc-runtime-2005-x86
    Revision:          4
    Reboot:            false
    Execute:           -
    Priority:          10
    Status:            Installed

Yet /query:m shows that removal is pending, and sure enough /synchronize will remove them: (on this occasion I'd manually installed the -x86 package before the main package hence it doesn't show up as pending removal)

Current profile packages:
Visual C++ 2005 Runtime (x64)
    ID:                vc-runtime-2005-x64
    Revision:          4
    Action:            Remove pending
    Reboot:            false
    Execute:           -
    Priority:          10
    Status:            Installed

I have just put 1.3.1-RC12 on (upgrading from 1.3.1-RC4), reverted my test machine to a clean image and tried again and the same problem happens.  Is there something I'm missing here?

I've also just done some further testing:  If I add the parent package (vc-runtime-2005) either directly into the profile associated with this computer, or as a dependency on a package listed in the profile, then the child package (vc-runtime-2005-x64) does not get queued for removal.  Originally the parent package was queued for reinstallation every time, until I added a check for a successful install in the parent package (shown above).  With those statements added, it no longer wants to reinstall the parent or remove the child package, but if I then remove the parent package from inclusion in the profile, the child package is again shown for removal.   (apologies if this sentence doesn't make sense)

Thanks,
Steve.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wpkg.org/pipermail/wpkg-users/attachments/20120808/ede34f13/attachment-0001.html>