Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Process of removing/retiring packages from Chum #118

Open
nephros opened this issue Feb 28, 2025 · 4 comments
Open

Process of removing/retiring packages from Chum #118

nephros opened this issue Feb 28, 2025 · 4 comments
Labels
question Further information is requested

Comments

@nephros
Copy link

nephros commented Feb 28, 2025

The team at Jolla/Jollyboys, and the people providing packages at Chum rarely, but increasingly often find themselves in the situation that a package has been published at Chum, and a release of Sailfish OS published at a later point ships the same software.

This causes the issue that Chum is suddenly in violation of the agreement that no Sailfish OS upstream packages be published on it.

This issue is created to document/discuss the process that can lead to the "retirement" of such to-be-obsoleted packages.

It is also created in the hopes that the Jollyboys team inform the Chum developers of such cases, so they can be handled ideally before the conflicting Sailfish OS release is going live.


Proposed process for retiring a package:

  1. Hopefully, a Chum package maintainer is informed in due time by the Sailfish OS team that retirement is necessary.

  2. Investigate differences in packaging. Things like subpackage names etc.

  3. If there are relevant differences in packaging, for existing, published repository versions of the chum package, publish a new revision which aligns the chum packaging with the Sailfish OS one. Take care of Obsoletes:, Conflicts: and so on. Think about the update case from the Chum to the Sailfish OS version and ensure a clean update path is possible.

  4. Identify the last SailfishOS release where the package may be published on Chum.

  5. Edit the .spec file so the package cannot be built on conflicting versions.

  6. Note that disabling build repos on OBS may seem like a viable strategy, but this puts all the work in the hands of the Chum maintainers, and errors may lead to unwanted binaries ending up published. This task is better left to the packager.

Strategies that may be used in .spec files to disable building:

ExclusiveArch: none

%if 0%{?sailfishos_version} >= 50500
ExclusiveArch: none
%endif

Depending/Conflicting with sailfish-version:

Requires:        sailfish-version < 5.0.0-1.1.1
BuildRequires:   sailfish-version < 5.0.0-1.1.1

Optionally, if the sailfishos-mirror organization now has a fork or clone repository, point submodules there instead of the original.

@nephros nephros added the question Further information is requested label Feb 28, 2025
@nephros
Copy link
Author

nephros commented Feb 28, 2025

pcre2: Retired with Sailfish OS 4.6

The described problem has appeared (AFAIK) first with the pcre2 package.

Chum links:

Sailfish OS links:

References:

keyutils: to be retired in SFOS 5.1

Sailfish OS 5.1 may/will ship keyutils

Chum links:

Sailfish OS links:

References:

ImageMagick: not retired

ImageMagick is present at the Sailfish github orga, but no packages have shipped. According to one employee on Telegram, it is used internally only.

@piggz
Copy link
Contributor

piggz commented Mar 16, 2025

I would support this. Is the best option for you to PR the above into the documentation?

Should we also cover the case of a package found to cause issues for users and needs to be removed/disabled? (as per recent forum discussions)

@nephros
Copy link
Author

nephros commented Mar 17, 2025

I would support this. Is the best option for you to PR the above into the documentation?

I can do that, but I'd leave the issue here open so retirement requests can go here.

Should we also cover the case of a package found to cause issues for users and needs to be removed/disabled? (as per recent forum discussions)

Sure, though I expect the process for such a case will need to be decided on a case-by-case basis. And how to decide a package is "bad enough" to warrant removal?

@nephros
Copy link
Author

nephros commented Mar 19, 2025

Another one: lz4

Installed       lz4-1.9.4+git1-1.1.2.jolla.aarch64 (installed)                  Extremely fast compression algorithm
Available       lz4-1.9.3.1-1.2.1.bso.aarch64 (sailfishos-chum)                 Extremely Fast Compression algorithm

The Jolla one is newer in 5.0 though

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants