Yes, that would be helpful! It wasn’t clear to me that the published library would end up being from my fork instead of updating the existing library according to the
library.json. Did it get that information from the
git remote of my working copy, or…? I did change the email of the author —assuming it would just apply to the new version onward— but that might be a separate issue from why it chose my fork for the identifier.
I can fix up the situation for my case by carefully using the
U8glib-HAL checked out directly from the main repo.
Would I have caught and fixed it if I had been given a warning and instructions? Maybe! Before publishing I’d like to have seen a list of all the existing libraries having the same
library.json information, with a mark on the one that I’m about to update, or a warning if I’m about to create a new one. As a maintainer, if I do want to change “identifying information” on a library, I’d like to be able to specify the library’s ID number, (or otherwise specify the “root” library, if there is such a thing in the db).
I can see why the library db should include alternative forks, and I imagine it’s a fun challenge to keep it working as well as it does. If it doesn’t have the concept of a “root version” at this time, that might be something to consider adding later. When there’s more than one with the same version identifier, but a different source URL or fork, pio prints the “library ambiguous” message. Would it be better or worse if pio assumed you meant the “root version” of the library whenever there’s more than one library with otherwise-matching information?