Bug in package prerequisites calculation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug in package prerequisites calculation

Chris Uppal-3
At least, I don't think it's by design.

When a package (re)calculates its prerequisites it doesn't take into account
the 'image stripper bytes'.  So if the image stripper itself (or one of the
objects it contains) is in a package that the first package does not otherwise
depend on, then it won't be considered to be a prerequisite.

Easy workaround is to add a manual prerequisite.

    -- chris


Reply | Threaded
Open this post in threaded view
|

Re: Bug in package prerequisites calculation

Blair McGlashan-2
"Chris Uppal" <[hidden email]> wrote in message
news:40040033$0$61059$[hidden email]...
> At least, I don't think it's by design.
>
> When a package (re)calculates its prerequisites it doesn't take into
account
> the 'image stripper bytes'.  So if the image stripper itself (or one of
the
> objects it contains) is in a package that the first package does not
otherwise
> depend on, then it won't be considered to be a prerequisite.
>
> Easy workaround is to add a manual prerequisite.

I think it is by design, but is the lazy option. A DPRO package could be
round tripped out to DVE/DSE, and obviously one doesn't want to lose the
image stripper configuration. This is why the opaque representation of the
image stripper as a serialised byte stream was originally used. Since only
DPRO can deserialize the image stripper bytes the decision was taken to
ignore these in prerequisites tracing. Of course this could be done
differently such that when running on DPRO the stripper bytes are considered
in the automatic prerequisites tracing. This would result in the calculated
prerequisites (potentially) being different depending on which version of
Dolphin was used to save the package, but I don't think that really matters.
I've recorded this as #1476.

Regards

Blair