-
Notifications
You must be signed in to change notification settings - Fork 6
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
Comments
pcre2: Retired with Sailfish OS 4.6The described problem has appeared (AFAIK) first with the Chum links:
Sailfish OS links:
References:
keyutils: to be retired in SFOS 5.1Sailfish OS 5.1 may/will ship keyutils Chum links:
Sailfish OS links:
References: ImageMagick: not retiredImageMagick is present at the Sailfish github orga, but no packages have shipped. According to one employee on Telegram, it is used internally only. |
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) |
I can do that, but I'd leave the issue here open so retirement requests can go here.
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? |
Another one:
The Jolla one is newer in 5.0 though |
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:
Hopefully, a Chum package maintainer is informed in due time by the Sailfish OS team that retirement is necessary.
Investigate differences in packaging. Things like subpackage names etc.
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.Identify the last SailfishOS release where the package may be published on Chum.
Edit the .spec file so the package cannot be built on conflicting versions.
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
Depending/Conflicting with
sailfish-version
:Optionally, if the
sailfishos-mirror
organization now has a fork or clone repository, point submodules there instead of the original.The text was updated successfully, but these errors were encountered: