[Cuis-dev] Something strange going on with package dependency version numbers

[Phil B]

I should probably expand on a common use case that resulted in these kinds
of problems in case it spurs any ideas:

Let's say I'm working in 3904 and doing all sorts of reorganizing (moving
classes between packages, add a new package here, remove a package there)
and then 3911 comes out.  Rather than updating my 'loaded' 3904 image to
3911 I will:

1) save (most of) my changed packages from the 3904 image
2) update a vanilla 3904 image to 3911
3) try reloading all my packages into the vanilla 3911 image

Many times something will fail so then I'll:

4) go back to my 'loaded' 3904 image and add/delete requirements and save
packages as needed to clean things up.
5) go back to 3 as necessary.

That often results in a hodge-podge of 'commit this package, discard that
one' etc. in the 3904 image which I don't care about since I'm going to
trash it once 3911 is built anyway.  But obviously, over time some version
mismatches have leaked out in my requirements and since version checking
was broken I found out about them all of them at once.

One thing that might be interesting is if we had a dependency validation
tool that could be used on one or more packages.  Then you could verify
from a requirements standpoint that the dependency graph was valid before
even trying to reload an image.

On Fri, Oct 11, 2019 at 8:29 PM Phil B <pbpublist at gmail.com> wrote:

> Juan,
>
> On Fri, Oct 11, 2019 at 12:01 PM Juan Vuletich <juan at jvuletich.org> wrote:
>
>> On 10/10/2019 10:36 PM, Phil B via Cuis-dev wrote:
>> > Ugh/yay! It's not a new bug...  it's a fix exposing issues from the
>> > old one.  I just found a package and dependent package having with a
>> > version issue with file timestamps from early September so the new
>> > code couldn't have caused that problem.  So when I'm rebuilding my
>> > image with the latest updates applied, any existing package dependency
>> > version issues that were previously being overlooked (and therefore I
>> > wasn't aware of) are now being reported.  That's my story and I'm
>> > sticking to it (for now... ;-)
>>
>> I have seen other cases where it seems that some prerequisite is
>> required with a revision number higher than what has actually been
>> saved. The only way I found for this to happen is:
>>
>> - Assume we have package A that requires package B. Both are loaded,
>> with correctly declared version and requirement.
>> - You modify some code in package B. B is marked dirty, and the revision
>> number is bumped by one. You don't save B.
>> - Use 'Installed Packages' tool. You select package A. On the
>> requirements list (at the bottom) you select package B and click on
>> [update] (bottom right button).
>> - The requirement of B in A is updated to the unsaved B revision number.
>> - Save A
>> - Exit without saving B
>>
>
> Yes, I do that *very* often but in a slightly different form:
> 1) Modify loaded package A
> 2) Modify loaded package B
> 3) Add a new requirement in package A on package B (not realizing that the
> version used was the unsaved version rather than the saved version)
> 4) Save changes to A
> 5) Discard changes to B
>
>
>>
>> Next time, you try to load A, and it can't find the required version of B.
>>
>
> Exactly.  So when the version checking was broken, A would load B.
> Ironically, now that things have been fixed... it's broken.
>
>
>>
>> The attach forbids updating requirement of B if B is dirty (unsaved).
>> Please take a look and see if it makes sense to you.
>>
>
> That makes sense (i.e. while it would still be valid to save package A
> with the requirement of the old (last saved) version of package B, I would
> agree that updating the requirement to an unsaved version probably should
> not be allowed or at least not done by default)
>
>
>> I also added, in case of failure, the description of the package with
>> the unfulfilled requirement, and the package the user actually was
>> trying to install.
>>
>
> OK, I applied both your update and Ken's and it's definitely an
> improvement.  A few things I noticed:
>
> 1) Using my Foo/Bar package example I get:
>
> Could not find package supplying: FeatureRequirement(Bar 1.2 to *.*)
> Required by: FeatureRequirement(Foo *.*)) For installing:
> FeatureRequirement(Foo *.*))
>
> Is there going to be a case where the 'required by:' and 'installing:'
> items can be different? (this actually relates to my next item which I
> meant to mention re: previous changes)  If so, could we only display both
> when they differ?  If not, then you're just listing the feature twice.
>
> 2) Something that used to be legal was that I could have a package named
> FooAlternate which provides: Foo.  Now it appears that the package and
> feature name must match.  I've actually been meaning to bring up for a
> while that I'd like packages to have better support for package
> name/provides mismatches, not removing the capability entirely... it's a
> useful option.
>
> 3) When you attempt to update a requirement to an unsaved package version
> you get a dialog with proceed and abandon buttons.  The option to proceed
> doesn't really make sense unless the intent was to allow the user to
> override (i.e. force updating to) of the unsaved version which it
> (currently) does not.
>
>
>> HTH.
>>
>> Thanks,
>>
>> --
>> Juan Vuletich
>>
>
> Thanks,
> Phil
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20191011/e98bbb51/attachment.htm>