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

[Phil B]

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/8b2a7dad/attachment-0001.htm>