storeman-developers / harbour-storeman-installer Goto Github PK

Copied from sailfishos-chum/sailfishos-chum-gui#7 (comment)

Jolla heavily opposes using ssu's global section for third party repositories, but this is what Storeman-Installer and Chum / Chum-GUI do. While I have not researched the technical background of this, the consequence for users is to be let down by the Jolla support (see web-link), because they simply state that you are doing it wrong (also see web-link). Thus @mentaljam, please evaluate, if a repository entry in the user section would also suffice.

DESCRIPTION

An unannounced and unreleased Sailfish OS version ("4.6") will change the way versions are handled in the ssu utility.

I imagine this may have an impact on how Installer handles/must handle OBS repository information, hence this issue.

ADDITIONAL INFORMATION

• sailfishos/ssu#16
• https://irclogs.sailfishos.org/logs/%23sailfishos/%23sailfishos.2024-04-11.log.html

This is the (much simpler) counterpart of storeman-developers/harbour-storeman#236. See there for the general aspects of this tasks.

Implementation details are already discussed here: storeman-developers/harbour-storeman@e1bca7d#commitcomment-79846301 ff.

Storeman Installer did not work as intended on an [email protected]

I did:

1. pkcon remove harbour-storeman
2. curl -LO https://openrepos.net/sites/default/files/packages/6416/harbour-storeman-installer-1.1.0-1.4.1.jolla_.noarch.rpm
3. pkcon install-local harbour-storeman-installer-1.1.0-1.4.1.jolla_.noarch.rpm
4. Tap on the Storeman Installer desktop icon: It starts, is busy for a while and closes itself.

While step 4 ran as expected, the icon is still the Storeman Installer icon!
Hitting it again simply re-does step 4!
A pkcon search name harbour-storeman only shows
Installed harbour-storeman-installer-1.1.0-1.4.1.jolla.noarch (installed) Storeman Installer for Sailfish OS
Available harbour-storeman-turing-0.0.26-1.armv7hl (openrepos-osetr) OpenRepos Client for Turing Phone
But ssu lr outputs
Enabled repositories (global):
- mentaljam-obs ... http://repo.merproject.org/obs/home:/mentaljam/3.2.1.20_armv7hl/

Thinking "WTF!" and "this must be a very simple shell script", I looked
at https://github.com/mentaljam/harbour-storeman-installer/blob/main/bin/harbour-storeman-installer
and https://github.com/mentaljam/harbour-storeman-installer/blob/main/harbour-storeman-installer.desktop
to be 100% sure to do the right thing and consequently executed harbour-storeman-installer at the CLI: Voilá, Storeman is installed!
Now a pkcon search name harbour-storeman shows

Installed       harbour-storeman-0.2.10+sfos3.2.20210906183000.9.ge94910a-1.9.1.jolla.armv7hl (installed)       OpenRepos Client for Sailfish OS
Available       harbour-storeman-debuginfo-0.2.10+sfos3.2.20210906183000.9.ge94910a-1.9.1.jolla.armv7hl (mentaljam-obs) Debug information for package harbour-storeman
Available       harbour-storeman-debugsource-0.2.10+sfos3.2.20210906183000.9.ge94910a-1.9.1.jolla.armv7hl (mentaljam-obs)       Debug sources for package harbour-storeman
Available       harbour-storeman-installer-1.1.0-1.4.1.jolla.noarch (openrepos-osetr)   Storeman Installer for Sailfish OS
Available       harbour-storeman-turing-0.0.26-1.armv7hl (openrepos-osetr)      OpenRepos Client for Turing Phone

I do not understand what was going on, do you?

But I think this would have been unresolvable for a pure GUI-user.

4.5.0.21

Sony Xperia 10 III

1.5.1 and 2.2.3:

BUG DESCRIPTION

Running the installer, both 2.2.3. and 1.5.1, does not result in an installed Storeman app nor logfiles.

STEPS TO REPRODUCE

2.2.3: execute the RPM. SF OS says installation was successful. I see no installation of Storeman. No log files in /var/log/

1.5.1: execute the RPM. "Install Storeman" app appears. Run "Install Storeman". Runs for a few seconds. App stops. No message, no log in /var/log/, no Storeman app.**

ATTACH LOG-FILE

There is no log file available :(.

Maybe some other logfile would be able to give more information?

ADDITIONAL INFORMATION

Not that I know of.

The "scriplet" shell code in the spec file (as of Storeman Installer v1.2.3 and below) seems to be inspired by https://sailfishdev.tumblr.com/post/184867320352/use-svg-image-for-app-icon-instead-of-png-ones

But rpmlint complains:

harbour-storeman-installer.noarch: W: wrong-icon-size /usr/share/icons/hicolor/86x86/apps/harbour-storeman-installer.png expected: 86x86 actual: 256x256

harbour-storeman-installer.noarch: W: wrong-icon-size /usr/share/icons/hicolor/172x172/apps/harbour-storeman-installer.png expected: 172x172 actual: 256x256

harbour-storeman-installer.noarch: W: wrong-icon-size /usr/share/icons/hicolor/128x128/apps/harbour-storeman-installer.png expected: 128x128 actual: 256x256

harbour-storeman-installer.noarch: W: wrong-icon-size /usr/share/icons/hicolor/108x108/apps/harbour-storeman-installer.png expected: 108x108 actual: 256x256

Your icon file is installed in a fixed-size directory, but has a largely incorrect size. Some desktop environments (e.g. GNOME) display them incorrectly.

and

harbour-storeman-installer.noarch: W: files-duplicated-waste 101664

Your package contains duplicated files that are not hard- or symlinks. You should use the %fdupes macro to link the files to one.

harbour-storeman-installer.noarch: W: files-duplicate /usr/share/icons/hicolor/86x86/apps/harbour-storeman-installer.png /usr/share/icons/hicolor/128x128/apps/harbour-storeman-installer.png:/usr/share/icons/hicolor/108x108/apps/harbour-storeman-installer.png:/usr/share/icons/hicolor/172x172/apps/harbour-storeman-installer.png

rpmlint errs sometimes, but is often right!

Side note: In case rpmlint complains correctly, classical fixed sized icons for Storeman Installer already exist at https://github.com/storeman-developers/harbour-storeman-installer/tree/master/.xdata/icons

@mentaljam asked at PR #36, "Is something wrong with the current way of generating icons?"
So maybe something is indeed wrong.

ToDo: Check what the Storeman Installer RPM really installs at /usr/share/icons/hicolor/*/apps/harbour-storeman-installer.png

When performing the migration from Storeman 0.2.9 to Storeman 0.2.10 (which resulted in issue #1), I wondered why this whole procedure has to be so complex for the user?
I.e. the usage description at https://openrepos.net/content/osetr/storeman-installer lets the user perform multiple steps, especially when migrating from Storeman ≤ 0.2.9!

Specific questions:

1. Why does one have to uninstall Storeman manually, before installing Storeman Installer?
   IMO you could execute in the %post section of the spec file
   if ! ssu lr | grep -qF mentaljam-obs; then
pkcon -y remove storeman || true
rm -f /var/cache/ssu/features.ini && ssu ur && ssu er mentaljam-obs || true
fi
   Edit (2022-12-23): This can and should be achieved via a Conflicts:, Obsoletes: and Provides: triple in the spec file, as implemented in Storeman Installer v1.3.1.
2. Why is it not possible to integrate / append the two lines of the mini shell script into the %post section of the spec file?
   Then the desktop icons etc. would become superfluous, but most importantly, the user does not have to manually start the Storeman Installer (at the GUI or CLI) any more! Storeman just would be installed by installing the Storeman Installer.

Plus two minor questions for checks & balances:

3. Why does the %postun script not ssu rr mentaljam-obs?
Well, it might be better to use a separate repo then (e.g. mentaljam-storeman), but IMO one should properly (and fully) restore the state before the initial installation after an uninstalling.
4. Do I understand correctly that with %{_datadir}/%{ssu_features_dir}/mentaljam-obs.ini in place plus an ssu er mentaljam-obs that is fully equivalent to ssu ar mentaljam-obs http://repo.merproject.org/obs/home:/mentaljam/%(release)_%(arch)/ && ssu er mentaljam-obs?
Due to issue #1 I was searching for an ssu ar command and wondered, if one can really do without it; i.e. if an ssu ar really does nothing more than creating an ini-file?

But as you are much more experienced in the topic "package management on SFOS" than me, I likely missed something crucial.

Please decide whether you wish to have Storeman Installer in Chum or not. On your request, I removed it from sailfishos:chum but left in sailfishos:chum:testing. According to Chum design, I would expect to have the same packages in the both. So, if you don't want to have the installer in sailfishos:chum, we should drop it from sailfishos:chum:testing as well.

@mentaljam, can you please pose a PR, which removes the git submodule mentaljam-obs. This does not seem to be possible via the GitHub web-frontend I am working with.

Thanks!