<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>