yab error on Hrev50906

[michel]

I updated from hrev50837 to Hrev50906. Simultaneously, yab was updated to 1.7.5.3-3, so now it is difficult to determine which is the culprit, but the combination gives a "could not resolve symbol" error (see attached screenshot)

This has also been reported on the yab forums.

[michel]

The issue has been duplicated on 3 different partitions, all with Haiku x86_gcc2

[michel]

I have attempted to downgrade yab all the way back to 1.7.5.2-1 and the error persists so it looks like the problem is on this side.

[KapiX]

hrev50893 is probably the culprit here. yab needs to be recompiled.

[bbjimmy]

A re-compiled yab does indeed work. Since we have libyab.so, only bound yab programs need to be re-done, programs that used the BuildFactory will update with a new libyab.so. Can someone please update yab and yab-IDE in the HaikuPorts repo?

[humdinger]

Uploaded newly built packages with hrev50914.

[korli]

@KapiX just to understand, are only yab binaries affected by the change in hrev50893?

[pulkomandy]

The changes are only to BControlLook, which is a private API. We did not declare it stable yet, so apps are using it at their own risk.

To be affected, an application would need to draw tabs without using BTabView and doing its own thing, using BControlLook to get the native look.

We can't easily move BControlLook to libshared, because it is used througout the interface kit. It is however in the BPrivate namespace, so developers are warned when they decide to use it.

[korli]

Yeah sure, the question was more about how to know which app needs to be rebuilt in a "stable" repo. Whether we have to check every app, or let the users find out themselves, which is not the best experience. In the end, it might be a bad idea to provide apps which uses such an API in our depot, when we cannot assert that it works correctly, or make them work again shortly. I'm wondering why I look like the only one to care about this...

[pulkomandy]

you are not the only one to care, however, I think the way to solve this is providing a stable version of the ABI, on which applications can rely (and this is also what people maintaining yab are requesting).

In other words, it is fine to break such things in the master branch. It is not fine to do it in the R1 branch where the API and ABI will always stay backward-compatible.

So, it is expected that such changes are getting into our master branch now, knowing that beta1 will be branched out "soon". If people miss the merge window, they would have to wait for R2, or add in some backwards compatibility symbols.

I still believe manually maintaining the apps in the depot and checking for these breakage manually is unrealistic. This is why I am trying to get the automated package build system set up on Haiku servers (with not much success so far - it seems very hard to get ssh access to some virtual machine and green light from sysadmins to set up the package build system there).

The plan is (as I see it):

• A stable "beta1" as a reference platform on which to build packages
• Buildbots running on this reference platform and using it to build things
• Resulting packages should run on beta1 and also on subsequent (bugfixes) updates to the R1 branch
• I don't care what happens to the R2/master branch, let the wild people breaking everything have fun there, or let them try to keep some compatibility, it's up to them
• Whenever we decide beta1 is too old and we need some more features in the baseline, we make a beta2. But, packages built on beta1 should still run on beta2, 3, etc until R1.
• Recipes could specify that they are compatible with a specific (older) version if they are sure they do not make use of APIs introduced later on.

I don't think there can be a variant on that plan that does not involve a baseline release. And we can't use alpha4.1 because it lacks the package infrastructure so we can't build packages using it as a reference.

[korli]

Sure it is the release plan, but until the release "happens", real users end up with half-backed things in nightlies, which brings in return bad PR. I wonder whether we could provide a "haiku_private" string, which we could bump on each such change. Some apps which we know they use private/unstable API could be more easily maintained this way (they can't be installed on a potentially incompatible version of haiku_private).

[pulkomandy]

The haiku package has version info, which should be used for that. See #10289 for how it is managed.

It changes at every hrev, however.

For R2 the plan would be to add soname versionning to the system libraries (libbe.so, whch would likely be split into one lib for each kit). We would bump the soname on changes to indicate that applications are not compatible anymore (and try to not do this too often). This would even allow multiple versions of the libs to coexist on the same system (so old apps can use old libs). It is unfortunately not possible to do that while staying compatible with BeOS (apps expect a single, unversionned, libbe.so).

We can experiment with adding an haiku_private provides to the Haiku package, but I would much prefer getting things in shape, releasing the beta, and using and bumping the version of the package instead.

Also, I'm not sure blocking the install of applications is the way to go. The private API is rather large parts of the OS (BControlLook, all the framework for HTTP, and the new MediaClient that Barrett is working on). There are breakage and changes all the time. So, an app which would otherwise run fine (because it uses only parts of the private API which didn't change), would be rejected at install time.

I think with a stable branch based on beta1, we can simply enforce a stricter "don't break things" rule, and before integrating patches there, require people to include all the required compatibility symbols needed (whenever possible - I have changes to the HTTP kit I will commit soon, that are not easy to cover with just adding some symbols). And, we should see about moving as much of BPrivate as possible to libshared.a or other static libraries, allowing apps to use a set and fixed version, and not suffer about changes while the API is still work in progress. This way the existing binaries continue to run, and the problem is detected only at buidl time (when compiling the app against new headers), leaving to developers the task of investigating and fixing the problem. Nothing should get into shared libs before its API is done and the ABI future-proofed with appropriate FBC padding, etc, allowing it to last for a few years.

[korli]

I checked x86_64 packages, none affected by this symbol change.