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

Package icons as subpackages #479

Closed
wants to merge 4 commits into from

Conversation

nephros
Copy link
Contributor

@nephros nephros commented Dec 3, 2024

Supporting two different filesystem locations depending on Sailfish OS version
while keeping the number of build environments to a minimum is problematic.

Instead of deciding where to install and what to package at build time, package and ship
both variants and let the package manager decide which is the right one.

See also: #472 (comment)

  • Package icons as subpackages
  • Copy generated icons around
  • Add Obsoletes, in order to provide an upgrade path

Things to test:

  • picks the correct package on SFOS 4.6 and/or 5.0
  • picks the correct package on SFOS 4.5 and lower
  • picks the correct package when updating from an installed Patchmanager version to the one including this change
  • Shows icon correctly after installation (for all of the above)
  • Removes icons at the meegotouch path and installs them at the silica location after/during an update from a lower version to SFOS 4.6
    SFOS GUI upgrades usually remove Patchmanager anyway AFAIK, so this last test may not be that important.

@nephros nephros added debt fallout and other issues originating from the past infrastructure building, packaging, hosting etc. labels Dec 3, 2024
@nephros nephros requested a review from Olf0 December 3, 2024 12:19
... so they get uninstalled properly (esp. when downgrading PM)
Copy link
Contributor

@Olf0 Olf0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From issue #472 comment-2514204204:

That should shift the burden to the package management solver and thereby solve (heh) our problems with build/install/SDK/release versions.

Cool, this PR proves (again) that "we can solve any problem by introducing an extra level of indirection"™.

But, as I have understood again that just also building with the SailfishOS-SDK for 4.6.0 in the ci_on_git-tags workflow completely resolves this issue (AFAIU), and exactly that already happens at SailfishOS:Chum (i.e. the SailfishOS-OBS), I think this is over-engineered.
I.e. I like it technically (but that is principally "because we can"™ do cool things by restructuring the packaging via reworking a spec file), but it introduces additional complexity which makes maintenance harder (especially if other people should continue maintaining Patchmanager, as it already happened twice).

Hence currently I do not think this is needed. But maybe I have not understood how this structural change might be helpful in the future.
I.e. if this PR solely resolves the minor issue of the ci_on_git-tags workflow currently not generating RPM packages suitable for SailfishOS ≥ 4.6.0, I strongly prefer to resolve this issue with a minor adaptation of the ci_on_git-tags workflow configuration file (I will do that soon™).

@Olf0
Copy link
Contributor

Olf0 commented Jan 13, 2025

I strongly prefer to resolve this issue with a minor adaptation of the ci_on_git-tags workflow configuration file (I will do that soon™).

Done per PR "[ci-on-tags.yml] Also build with SDK for 4.6.0" #485.

@nephros
Copy link
Contributor Author

nephros commented Jan 15, 2025

Closing as another solution was implemented.

@nephros nephros closed this Jan 15, 2025
Olf0 added a commit that referenced this pull request Jan 15, 2025
* [ci-on-tags.yml] Also build with SDK for 4.6.0

See #479 (review)

* [.github/workflows/ci-on-tags.yml] Align comment to recent changes

* [.github/workflows/ci-on-tags.yml] Improve comment
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
debt fallout and other issues originating from the past infrastructure building, packaging, hosting etc.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants