LibICU issues across SFOS releases

Applications
#1

Im Amazfish, i use some KDE KF5 and Kexi DB libraries for database access. The SQLite driver for Kexi links against libicu. Unfortunately, the libicu version in SFOS changes across releases, I used to work around this by shipping my own version of libicu, but that what always fragile, and now isnt working at all. it seems programs dont like to load multiple libicu versions. The current issue is that SFOS 3.3 has libicu63, and 3.4 has libicu66. I thought I could work around it by shipping libicu66 with the app for 3.3 users, but that isnt working, it just fails to create/open the database, with strace showing it faulting in libicu. If i symlink the 63 versions to 66, then the app works fine.

What options do I have? It looks like I can only support one SFOS release at a time now, meaning users are going to complain whenever there is an EA release, and there is a delay to the new target appearing on OBS to allow me to rebuild the db drivers.

2 Likes
#2

I would build the package in a separate repository whenever
there is a new icu version and merge the new version when that version is in the the current release.

About the complaining: users will always complain but there’s a reason that EA is EA.
If you want to rebuild kdb against the new icu update for ea you can install that to the repo where the kdb package is build.

#3

Yes, i was thinking something like this … it may be better for me to build amazifsh on OBS along with its associated libs (like rinigus) and release from there, instead of from the SDK … long live OBS!

#4

Have the same issue as @piggz with the maps software. For me, solution was so far to support multiple SFOS versions at OBS and switch OpenRepos version to support the latest SFOS.

There are two delays imposed in the process:

  • availability of new target at OBS. Usually, released with smallish delay after proper release. For example, right now we don’t have 3.4.0.x at OBS
  • when my primary device gets updated. As it is community port, it may take bit of time before I get the update done.

To reduce the delay, I try to support new target at OBS as soon as it is available. So, it is possible for users to install the apps from there.

It would help if we would have some support from Storeman for OBS repos. Or some combination with OpenRepos/Storeman that would allow us to publish apps with separate repositories for different SFOS versions. Not sure how simple would it be though.

I must admit here that I stopped updating maps stack for SFOS versions before 3.3 with the release of 3.3. That’s due to the ability to use system-provided gcc allowing me to drop the hack with opt-gcc. Which simplified packaging and compiling. But, with the new version of SFOS coming up, I would probably support 3.3 for a while, as I did with older versions before. Well, as long as it is feasible … at OBS.

#5

I assumed I was having a similar issue to you with maps software. It seems like the solution is to package on OBS and disable targets as they stop being supported. Like you, I will probably only support 3.3 and 3.4 for now, and a rolling 2 releases. I will probably use the SDK locally for dev/testing, as I can work around library versions on my own device, but actual packaging will have to be via OBS, with the old application only available for older OS releases from there.

Long live OBS! :wink:

#6

It should be possible to have two RPMs in the Openrepos repo, where each has a exact depencency on the (ICU) library needed (through exact dep in the .spec file).

Pkcon should then be able to resolve the correct version that can be installed depending on the availability of the correct lib version.

Am I wrong in assuming this? Will pkcon decide to always use the newest version, and then fail to install because the dep is unavailable?

In any case, using coderus’ docker build images (e.g. through gitlab CI or github actions) allows to build against several SFOS releases, and this can be automated.

#7

Writing automation scripts for docker builds of projects involving multiple libraries sounds very much as writing your own OBS. In principle, you start solving the problem for which a working solution exists already instead of working on something that is new.

As for making versions for targeted ICUs and then dumping them into the same repo - might work. Just again, it is a mess from developer POV. I suspect that I will be missing once in a while one or another build. :slight_smile:

#8

For complex projects, sure. For a single app (or lib) which just needs to be built against different library versions in different OS releases, I think it’s a passable solution.

As an example, here’s how I do it for one that needs to link to different glibc versions:

.gitlab-ci.yml (disregard the clumsy build script and “deploy stage” that’s stupid and doesn’t work)

#9

I agree, for simpler apps (in terms of dependencies, not content), it is reasonable solution. Here we are talking about more complicated cases with number of dependencies that are not available as SFOS base libs. As in case of @piggz and mine.

1 Like
#10

Part of the issue is that the application itself doesnt depend on a specific icu version, its one of the supporting libraries. By having multiple copies of the libs and app depending on specific versions, it might be possible to make it work, but its just a whole extra level of effort id rather not have to worry about, being that ive plenty of other stuff to get on with! :slight_smile:

#11

I think that was planed at some point. I remember that there were plans for an API. IMHO an import of OBS repo and meta data from appstream would be perfect.

#12

No, that works well with pkcon: Storeman and crypto-sdcard are using this scheme.
For details, i.e. how to employ the necessary dependency scheme, RPM naming scheme etc., read this documentation.

P.S.: Lately, there seem to be issues with this scheme when using Storeman (while resorting to the command line and using pkcon always works), but that needs further investigation.

#13

Hopefully with OBS Chum / OpenRepos+Storeman integration, this will resolve without any fiddling and enforcing dependencies.