Abcd ejstt gggb

102

The using of libsolv to manage package dependencies is only the first part of packaging work. The second one, much more involving, is to actually design the packages (what exactly they contain) and their dependencies.

Again, I will speak about how this problem is handled with deb/dpkg/apt. When more than one implementation of some library exist in repository, they both provide the same impementing virtual package. When some software needs the functionality regardless of the concrete implementing, it is made dependent on the virtual package. One implementing package is marked as the default. So when no implementation is installed at all this real package is installed.

So, consider libjpeg virtual package (contains no files, only dependencies) and 2 its implementing packages jpeg2000 and jpeg-turbo, both provide libjpeg. One of them is default, say jpeg-turbo.

  • When someone installs a package that requires libjpeg, the system checks if libjpeg is installed. This only happens when either of its implementations is installed. When none is, the default jpeg-turbo is installed as well as libjpeg which it provides.
  • When now someone installs some other package that requires concrete jpeg2000 package, this one is installed, also providing libjpeg. In this case jpeg2000 is installed as required but jpeg-turbo is installed as dependency of libjpeg and is uninstalled.
  • In case there are 2 packages, one depends on jpeg2000 and another on jpeg-turbo, no conflict exists, and provision of 2 implementations of libjpeg is irrelevant.
  • In case there are 3 packages, one depends on jpeg2000, one on jpeg-turbo and one one libjpeg, the latter can link against whatever finds first or against the default implementation jpeg-turbo (because both provide the same symbols, it is expected to be possible to link with either).
103

Thank you for your contribution to this topic, alpopa!

Unfortunately, I do not speak the English language and therefore try to Dr. Google translater.
Very helpful, sometimes (felt) excellent translations, sometimes irritating, misinterpreting, amusing but also insulting!
Therefore I cannot tell whether your contribution is (also!) addressed to me, or (probably!) more to insiders.

104

Hi @Polli,

My message is for package maintainers, not for you.

I want to assure you my message contains only (more or less) technical details on how such problems can be solved. The message tries to not insult anybody.

105

Moin alpopa,

I also understood your message to mean that it was intended for insiders (package maintainers). But I wanted to be sure that it was so.
The interpretations (translations) of the Google Translator can (sometimes) ‘deliver’ condolences (= Wrong translation?).
This was only intended as a note and in no way refers to your lines!

106

Haiku has a package alias system for this AFAIK. So perhaps both libjpeg and libjpeg_turbo can “provide” the package lib:libjpeg (corresponding to libjpeg.so?), and apps can then depend on lib:libjpeg and be implementation-independent.

1 Like
107

The problem is not at the packaging level in this case.

Indeed, our dependencies do not use concrete and virtual packages. Instead, packages directly expose an entry for each library. It uses the lib: prefix and the name of the library, indeed lib:libjpeg is for libjpeg.so.

In this case, we have two packages providing the same thing (lib:libjpeg.so) and other packages depending on it. So far so good.

The problem is that the dependency on a library is versionned. For this we use the library soname, which defines the library version and ABI. We can’t really do otherwise: if the soname is different, the ABI is different, and therefore the packages cannot be drop-in replacement for each other. They can, however, be installed side by side, and all will be fine then.

We should just do that. The packages provide two different libraries (with the same name, but different ABIs) and they can live side by side.

So, where is the problem now? The problem is that the libjpeg recipe had been disabled and completely removed from the repos. Why was that done? Because building new packages would keep using it, when we wanted them to use libjpeg_turbo instead. How can we make things better? I suggest removing just the _devel package of libjpeg. This way, already built apps using it can just continue using it, and next time they are rebuilt, they will switch to libjpeg_turbo. After waiting long enough, we can consider removing the libjpeg package (we need some definition of “long enough”, it can be a few years, it can be when we release R1 and subsequently break the ABI, it can be when we have checked no other existing package needs it anymore, for example).

I have done this for the ICU 57 recipe (being replaced by icu 66). It seems to be working fine so far. I think Korli has restored libjpeg with a similar fix. We’ll try to keep to this approach and hopefully there will be less of such problems in the future.

Sorry about this, we are still experimenting with our package management and the way we handle things. That’s also one reason we are in beta, to find and fix bugs in the process and not only in the code.

4 Likes
108

Google-Translator German > English

If anyone is interested in (dewy) log files, reports, etc. (in connection with OpenJDK + Ancestris on Haiku, …):
For life and health, I build a virgin SSD into my Zotac ZBOX IQ01 and provide partitions for Windows10, Haiku32 (daily / nightly) + Haiku64 (daily / nightly) and for shared data.

Korli kindly created a recipe for Ancestris10 (official stable version) and at the same time ‘solved’ the problem with libjpeg_9.3 (installation OpenJDK11) for it.
But I also want to test Ancestris11 (daily / nightly), otherwise I will miss too many updates!

If:
How should I proceed in order to achieve real and usable (helpful) results (log files, reports, …, screen shots)?
Memory:
After the first Ancestris Start click, different error messages appear, which must be left as they are, otherwise Ancestris (10 + 11) will not start with a second Start click!

109

SceenShoot (excerpt) include IPv6 …

include_IPv6

110

Möchtest du mitschreiben was das Programm beim ausführen ausgibt, dann starte es über den Terminal:

cd /pfad/zum/programmordner
programm-name > /boot/home/programmname.log
1 Like
111

Danke für den Hinweis, Lelldorin!

112

Hello!
I don’t know if it’s relevant. After starting Ancestris11-Haiku64 the following log file was written:
hs_err_pid1471.log
Upload is not allowed.

113

Zurga from the Ancestris team wrote to me:

Seems to me that the problem is still in Java port, only Netbeans is initializing and trouble with getting network adapter information.
The stack trace shows trouble in libnet.so

114

It’s a reported issue: https://github.com/haikuports/haikuports/issues/4212

1 Like
115

Thanks Korli!
I am really an ‘unprepared’ user to be able to have a say here.
I uninstalled the ‘netbeans_bin 8.2-1’ (HaikuDepot) and everything works as before.

116

OpenJDK 8 has been rebuilt and Ancestris 11 (latest, nightly) starts without error message!
Thanks for that!

1 Like
117

Google-Translator:

Korli, you were kind enough to create a recipe for Ancestris and make it available for installation via HaikuDepot.
At the moment, OpenJDK11 is (still) installed in parallel.

According to Zurga (Ancestris Support), Ancestris 10 (stable version) requires OpenJDK8, so it is not fully compatible with OpenJDK11.
Whereas Ancestris 11 (updated almost daily, nightly) is ‘also’ fully compatible with OpenJDK11.

Ancestris-Documentation: “We recommend you use Java 8.”
https://docs.ancestris.org/books/user-guide/page/java-installation

I prefer the ‘future’ version Ancestris11, because it is updated almost daily / nightly.

The previous Java error message before Ancestis was started occurred once after Ancestris was started. However, not immediately afterwards, but only after clicking on (forgotten). Ancestris was then terminated, but could be restarted immediately without Java complaining again.
Ancestris11 started in the window for the first time (as always), but then as I ended it.

There are some (perhaps unimportant) little things, if you are interested.

Addendum:
The above applies ONLY to Haiku 64Bit!
Ancestris starts under Haiku-32Bit (with a Java error message before Ancestris starts), but behaves completely differently and virtually unusable.

118

Another aspect of java apps… it seem majority java write configuration file with dot version
aka .appname and not on /boot/home/config.
it seem default there set on java/jre?

121

Openjdk11 is now upgraded to 11.0.9. Hope it helps. Please check if issues you see are already reported:

3 Likes
122

Thank you Korli for your commitment!

123

Yes, Korli, it helps! Thank you!
Now Ancestris11 starts under Haiku64Bit with OpenJDK8 and OpenJDK11 without an error message!

Ancestris11-Haiku64-OpenJDK11.0.9+11

Addendum:
Unfortunately ONLY if openjdk10_bin is installed at the same time (see following post)!

2 Likes