search

sailfishos-chum / main

Documentation and issue tracker for the SailfishOS:Chum community repository
https://build.merproject.org/project/show/sailfishos:chum
MIT License
26 stars 4 forks source link

nettle and gnutls repositories #26

Closed razcampagne closed 2 years ago

razcampagne commented 2 years ago

Hi,

I packaged a newer gnutls as well as one of its dependencies, nettle, and would like for them to be part of chum. You can clone from these repositories:

https://redmine.casenave.fr/projects/gnutls-spec/repository https://redmine.casenave.fr/projects/nettle-spec/repository

Thanks!

rinigus commented 2 years ago

We have so far avoided packaging libs that are part of SFOS already. See the first paragraph at https://github.com/sailfishos-chum/main#how-to-use-these-repositories-developers

Before we would start pushing this types of libs into Chum, we would all have to agree that it is a good thing to do. I am mainly afraid of issues with the other software that can be triggered by such inclusion.

razcampagne commented 2 years ago

Oh, I must have missed this part of the documentation. But I am aware of potential issues with the existing library, thus I renamed my package gnutls37 (for version 3.7.x) and made sure it would not conflict with the official package. gnutls37-devel will conflict with gnutls-devel (from jolla) because only one package can install the .so file but this shouldn't affect end users.

The reason I packaged this is emacs' package manager is nearly unusable without a recent gnutls lib.

rinigus commented 2 years ago

Let's see whether @piggz has different opinion. I think we shouldn't add anything that could uninstall or interfere with the system packages.

As far as I know, some packages could request the dependency via Provides that can be done via .so as well. So, even if user will not install your package by name, it could lead to some kind of interference when trying to add something else.

However, it is not all bleak if @piggz agrees with me. You could add these packages to your own OBS repository. Which is not ideal...

razcampagne commented 2 years ago

I think we shouldn't add anything that could uninstall or interfere with the system packages.

I agree with you on this, that’s why I tried to be careful and not break anything.

Let me explain my reasoning, just tell me where I’m wrong.

Official gnutls package is at version 2.12.24. Included files are: libgnutls.so.26 and libgnutlsxx.so.27 There are of course other files but let’s say they’re not important and I don’t include them in my package anyway so they can’t conflict.

My gnutls37 package is at version 3.7.2 and includes libgnutls.so.30. Another package gnutls37-c++ includes libgnutlsxx.so.28 As you can see, both versions can cohabit (I have them both installed on my phone right now) and should not interfere with each other.

The case for -devel packages is a bit different. gnutls-devel and gnutls37-devel will* conflict (and I specifically added the conflict directive in spec file) because they both includes the same files (header files and libgnutls.so symlink to their respective library file). But! These packages should only be useful to developers building their software and they can choose either jolla provided gnutls-devel package or gnutls37-devel but only if they add an unofficial repository (chum if you accept it) and specify this package name in their spec file.

As far as I know, some packages could request the dependency via Provides that can be done via .so as well. So, even if user will not install your package by name, it could lead to some kind of interference when trying to add something else.

I am in no way an rpm packaging expert but if I understand correctly this Provides feature and what you mean, this shouldn’t be an issue. rpm relies on ldd to know which library is needed and it will always list up real library files and not symlinks so there should be no way it will try to install the wrong dependency.

For example, libcups.so.2 from cups-libs is linked with libgnutls.so.26, provided by the original gnutls package. emacs, packaged by myself is linked with libgnutls.so.30, provided by gnutls37.

However, it is not all bleak if @piggz agrees with me. You could add these packages to your own OBS repository. Which is not ideal...

Of course, I can still provide these packages to another repository on OBS or even on OpenRepos. But I do like the idea of a single community repository properly maintained :) If you still consider this proposition too dangerous for chum, I won’t push it any further and I’ll try to find another solution but I do think this particular case to be pretty much harmless. After all, gnutls on sailfishos is a dependency to only a single package, cups-libs.

rinigus commented 2 years ago

Thank you for your explanation! It does sound reasonable and I just understood that .so file was the one in the regular package. Maybe we should include it then. However, in this case, we would have to follow SFOS releases and make this package disabled for every new release by default. Only after confirming that the package .so.XX is different from the release, we can switch compilation "on" for that version. But that all goes to the _service file at OBS.

I would wait still for @piggz feedback and then we can proceed.

piggz commented 2 years ago

After reading the explanation, it does seem reasonable. Is there a reason sfos has stuck on the older version, and could you PR updates upstream in parallel to having it in chum? Ive no objection to it being included as it seems reasonable steps have been taken.

razcampagne commented 2 years ago

Great, thanks! I'll send a PR to upstream. I thought they kept an older version because of license issues but it doesn't seem to be the case. Disabling it on chum by default for new releases is also a good idea.

rinigus commented 2 years ago

I will import the repositories into github chum and then I hope you can make submission requests at OBS. Will make you maintainer at those Github repos.

rinigus commented 2 years ago

Looks line gnutls has tar.xz over there as well as submodule. I presume tar.xz is not needed and should be removed. Right?

razcampagne commented 2 years ago

Yes, I'll do submissions at OBS, I already have a setup there.

Looks line gnutls has tar.xz over there as well as submodule. I presume tar.xz is not needed and should be removed. Right?

Actually, it's the submodule that is not needed anymore. I tried with it first but sfos lacks a command to generate the configure file so I went with the official tarball instead. I hope it's not an issue. I'll remove the .submodule file.

rinigus commented 2 years ago

if you have it with tar.xz we don't need to have it in github at all. It can be just at OBS, as far as I have seen. Just make sure to have copy for backup purposes somewhere. We have several packages that are using this approach in Chum already.

In this case we have to copy repository nettle only, right?

razcampagne commented 2 years ago

I looked a bit on github for similar packages and found kyotocabinet that included a tarball and used _service file from OBS to update from git so I did the same.

I guess I can do without a repository in chum organization.

Okay for nettle repository.

rinigus commented 2 years ago

right, kyoto was packaged that way. I'll pull them both as they are and lets distribute it from here. sorry for delay.

rinigus commented 2 years ago

here you go - repos are made and you maintainer. Looking forward to submission request at OBS.

razcampagne commented 2 years ago

I'm sorry, I finally found some time to get to work on these packages but the invitations you sent have expired :( Could you send them again, please?

rinigus commented 2 years ago

Done.

razcampagne commented 2 years ago

Thanks!

razcampagne commented 2 years ago

Packages have been submitted and build properly on sailfishos:chum. Closing this ticket.

Thanks.