Package prerequisites

Hi Blair,

I noticed a problem with loading packages into a fresh beta 2 image on the
NT4 machine in my office. In particular, it loaded my PenWindows package.
It got my attention because that package will install under NT/2k, but, will
uninstall only on 9x; actually, it breaks anything that traces
prerequisites.  The interesting question is why it loaded the package; it
shouldn't have needed to do so.

Partly for achival purposes, and partly because PenWindows "won't go away"
(even when disabled, it makes its presence known), I have various packages
named "PenWindows *.pac".  I've been doing a lot of moving things between
the packages to make it possible to uninstall the offensive parts of
PenWindows.  Actually, the plan is to build a "final" D5 image by simply not
installing the bad stuff, and leave my D4 image as-is.

The problem appears to be that the change in its dependence occured after
the package was saved.  Browsing its prerequisites gives the correct
information, but, the file is out of synch, and still points back to
PenWindows instead of the correct pacakge.

So, I think the real bug (in D4) is that the package thinks it doesn't need
to be saved when in fact it does.  With that said, I'm not sure what can (or
should) be done about it.  Is there a way to safely mark pakages as changed
any time one of its prerequisites changes?  That would have to work even
when cycles occur.  Obviously the packages in a cycle shouldn't save
themselves, but, they might need to mark themselves as changed.

A dubugging note: I found the offending package by placing a breakpoint in
the pre-install script of PenWindows.pac (in D4), and loading that into D5.
It traced back to a package that shouldn't have depended on PenWindows.pac,
and the rest made sense (eventually<g>).


Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Schwab" <[hidden email]> wrote in message
news:[hidden email]...
> Hi Blair,
>
> I noticed a problem with loading packages into a fresh beta 2 image on the
> NT4 machine in my office. In particular, it loaded my PenWindows package.
> It got my attention because that package will install under NT/2k, but,
will
> uninstall only on 9x; actually, it breaks anything that traces
> prerequisites.  The interesting question is why it loaded the package; it
> shouldn't have needed to do so.
>

It will load whatever is listed in the package file. Look for the bit that
starts:
package setPrerequisites: (IdentitySet new

add: etc

yourself).

The content there would have been that calculated by the automatic
pre-requisite tracing done when the package was saved. If there is something
there you aren't expecting, then you can use the pre-reqs tree in the PB to
find out what is causing the dependency.

> The problem appears to be that the change in its dependence occured after
> the package was saved.  Browsing its prerequisites gives the correct
> information, but, the file is out of synch, and still points back to
> PenWindows instead of the correct pacakge.
>
> So, I think the real bug (in D4) is that the package thinks it doesn't
need
> to be saved when in fact it does.  With that said, I'm not sure what can
(or
> should) be done about it.  Is there a way to safely mark pakages as
changed
> any time one of its prerequisites changes?  That would have to work even
> when cycles occur.  Obviously the packages in a cycle shouldn't save
> themselves, but, they might need to mark themselves as changed.

In D5 if the pathname of a package is changed then all dependent packages
are marked as changed. D4 did not do that (the defect no. is 377).

Regards

Blair

Blair,

Understood.  The problem is that the package was saved with old information,
and didn't mark itself as changed when the content of prerequisite packages
changed.


> In D5 if the pathname of a package is changed then all dependent packages
> are marked as changed. D4 did not do that (the defect no. is 377).

That's the kind of thing that would have prevented this, although it would
have to mark the dependent packages as changed when classes come or go from
a package.

I'll poke around in D5 a little to see if it's still an issue.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]