<div dir="ltr">I should probably expand on a common use case that resulted in these kinds of problems in case it spurs any ideas:<div><br></div><div>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:<div><br><div>1) save (most of) my changed packages from the 3904 image</div><div>2) update a vanilla 3904 image to 3911</div><div>3) try reloading all my packages into the vanilla 3911 image</div><div><br></div><div>Many times something will fail so then I'll:</div><div><br></div><div>4) go back to my 'loaded' 3904 image and add/delete requirements and save packages as needed to clean things up.</div><div>5) go back to 3 as necessary.</div><div><br></div><div>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.<br></div></div></div><div><br></div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 11, 2019 at 8:29 PM Phil B <<a href="mailto:pbpublist@gmail.com">pbpublist@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Juan,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 11, 2019 at 12:01 PM Juan Vuletich <<a href="mailto:juan@jvuletich.org" target="_blank">juan@jvuletich.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 10/10/2019 10:36 PM, Phil B via Cuis-dev wrote:<br>
> Ugh/yay! It's not a new bug...  it's a fix exposing issues from the <br>
> old one.  I just found a package and dependent package having with a <br>
> version issue with file timestamps from early September so the new <br>
> code couldn't have caused that problem.  So when I'm rebuilding my <br>
> image with the latest updates applied, any existing package dependency <br>
> version issues that were previously being overlooked (and therefore I <br>
> wasn't aware of) are now being reported.  That's my story and I'm <br>
> sticking to it (for now... ;-)<br>
<br>
I have seen other cases where it seems that some prerequisite is <br>
required with a revision number higher than what has actually been <br>
saved. The only way I found for this to happen is:<br>
<br>
- Assume we have package A that requires package B. Both are loaded, <br>
with correctly declared version and requirement.<br>
- You modify some code in package B. B is marked dirty, and the revision <br>
number is bumped by one. You don't save B.<br>
- Use 'Installed Packages' tool. You select package A. On the <br>
requirements list (at the bottom) you select package B and click on <br>
[update] (bottom right button).<br>
- The requirement of B in A is updated to the unsaved B revision number.<br>
- Save A<br>
- Exit without saving B<br></blockquote><div><br></div><div>Yes, I do that *very* often but in a slightly different form:</div><div>1) Modify loaded package A</div><div>2) Modify loaded package B</div><div>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)</div><div>4) Save changes to A</div><div>5) Discard changes to B</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Next time, you try to load A, and it can't find the required version of B.<br></blockquote><div><br></div><div>Exactly.  So when the version checking was broken, A would load B.  Ironically, now that things have been fixed... it's broken.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The attach forbids updating requirement of B if B is dirty (unsaved). <br>
Please take a look and see if it makes sense to you.<br></blockquote><div><br></div><div></div><div>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)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I also added, in case of failure, the description of the package with <br>
the unfulfilled requirement, and the package the user actually was <br>
trying to install.<br></blockquote><div><br></div><div>OK, I applied both your update and Ken's and it's definitely an improvement.  A few things I noticed:</div><div><br></div><div>1) Using my Foo/Bar package example I get:</div><div><br></div><div>Could not find package supplying: FeatureRequirement(Bar 1.2 to *.*) Required by: FeatureRequirement(Foo *.*)) For installing: FeatureRequirement(Foo *.*)) <br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
HTH.<br>
<br>
Thanks,<br>
<br>
-- <br>
Juan Vuletich<br></blockquote><div><br></div><div>Thanks,</div><div>Phil </div></div></div>
</blockquote></div>