I’m wondering if anyone else is seeing this error in SoftwareUpdater or is my Beta2 install on my ThinkPad cursed?
Option 1 looks like it rollback my install and uninstall all the third party software I installed from HaikuDepot which would be extremely annoying.
Option 2 says I can use an excluded version of the missing libray but that option does not allow my ThinkPad to update
So I am stuck with Option 3 of ignoring the issue and cancelling the update.
Thanks.
There is a new version of the Noto fonts but unfortunately it has a “lower” version number (2.7) because of a change of the way things are versionned by Noto fonts developers.
Apparently this confuses the update system? I did test the change to Noto locally and had no problem booting, and as far as I can see, the Haiku package shouldn’t depend on a specific version, so I’m not sure why it’s complaining here. But I installed the font package manually.
There is no version declared in the haiku package information so it automatically adds a dependency of >= to whatever it was built against. Obviously 2.7 < 20170920, so…
Specifying a version inside the haiku PackageInfo should help. Please submit a fix for this sooner rather than later, as it will also have broken beta2 updates 
Yep - my updates barfed the same message at me just now…
Is the package versioning lacking some mechanism to deal with such versioning changes? Other package management systems provide a way to bump a package version above all previous releases, e.g. the “epoch” field in Arch Linux’ or Debian’s package management.
The whole point of versioning is to ensure you install newer package than is already installed. The newer package is not that with more recent release date, but that with greater version number, taken alphanumerically. And as pointed by @waddlesplash, formally 2.7 < 20170920.
Of course, almost each package manager is able to install a package with lower version number, but this action is considered downgrade and package manager usually complains about it, so extra confirmation or extra manual action is necessary.
This kind of situation arise sometimes in more mature projects (I recall Debian once had something like this) and in such cases an article is published at project’s website with apologies for inconvenience and instructions about how to deal with this situation.
Hence, as phw explains, other systems have an “epoch” field so the packager just increments the epoch to reflect a new numbering system and taking epoch into account 2:2.7 is newer than 1:20170920
Yes, exactly. The culprit here is a change of a versioning scheme from upstream. So before that they versioned using dates, now they version using dotted numbers.
Of course saying “meh” is one way to deal with it 
But other package management systems have mechanisms to deal with this cleanly, e.g. the epoch. If this would happen to an Arch Linux or Debian package the maintainer would raise the epoch number. Packages with a higher epoch number are always newer then packages with a lower one or none at all. So in this situation It would result in 1:2.7 > 20170920 (with the 1 before the colon being the epoch). This would be expected result and would allow the package manager to deal with the situation without requiring the user to fix it manually.
Well, the problem here is not only in the version downgrade, it’s in me not understanding that the Haiku package would depend on an explicit version, and doing the update to Noto before going to sleep, leading to a 24 hours delay before the fix.
SoftwareUpdater always does a “full sync” and has no problem downgrading packages if the repositories say so. So, if done correctly, there would be no problems for users.
Also, such versionning scheme changes happen rarely enough that it’s not a high priority thing. The “epoch” field could be added if soemeone wants to contribute a patch adding it, but it will be in addition to the version and revision, and that make things more confusing than they need to, all the time, to fix a problem that only happens very rarely. Is it worth it?
The Haiku package was fixed yesterday, updates with SoftwareUpdater should work again. For those of you using pkgman, remember to check pkgman full-sync from time to time to see if it does more updates than what the simple pkgman update does.
Thank you. This issue now resolved as I can now update my Haiku install error free with SoftwareUpdater.