Optionally allow SFOS:Chum GUI app to ignore vendor changes when updating packages

[Olf0]

@nephros discovered that packagekitd ignores a vendor change if the method install is called for updating packages (instead of the method update). See that aforelinked thread for rationale and details.

This could be easily done for a single-package update by changing update to install in line 398 of src/chum.cpp, but I do not know if this is the best way to implement this change and how to adapt that for updateAllPackages. Furthermore the whole scheme of ignoring vendor changes when updating packages should be opt-in only, so it requires a switch in the settings.

I would appreciate much, if @rinigus and / or @piggz retraces the rationale and replies here, if this consideration is sound in your opinion. Implementing this change should be a minor task for any experienced C++ programmer, when we reached consensus that this change constitutes an enhancement.

[rinigus]

Vendor was added to allow users to choose whether they use Chum or some other repository for particular package.

Let's say you prefer Chum for package A that is also available in Jolla Store and OpenRepos. Without vendor, you would be on mercy of version-release differences between streams. For example, Jolla Store could have the same version but with larger release.

Same goes for opposite - I may prefer OpenRepos for some package to Chum.

So, vendor allows to pin the source of the package - as it is expected. While it causes issues for those who want to jump from one source to another, it prevents the issues that we will get by changing the source of the package automatically.

I consider it a feature and the needed one.

[Olf0]

I consider it a feature and the needed one.

This is definitely the case for OpenRepos (and hence Storeman) as I documented recently.

But the assessment is different for the SailfishOS:Chum repository, hence I wrote this suggestion above.

Actually there seems to be some misunderstanding in details:

• "Without vendor, you would be on mercy of version-release differences between streams."
  • This suggestion is not about eliminating vendor tag, which also is impossible for other "streams" (repositories), e.g., the Jolla Store.
  • Merely evaluating the version-release differences for a package in SailfishOS:Chum (compared to the same package in other repositories) might be wanted behaviour for some.
• "For example, Jolla Store could have the same version but with larger release." For this case the change suggested here would make no difference at all, because the SailfishOS:Chum GUI app does not access the Jolla Store rsp. its repository.
• "So, vendor allows to pin the source of the package - as it is expected." Though the first half of this statement is absolutely true, it is not what some people expect: They want the newest version, wherever it comes from. The SailfishOS:Chum GUI app could provide this with packages from SailfishOS:Chum (only).
• "While it causes issues for those who want to jump from one source to another, it prevents the issues that we will get by changing the source of the package automatically." Which issues do you mean to address here? This is exactly the reason why my assessment for SailfishOS:Chum is different than for OpenRepos:
  • "System package"-superseding packages are not allowed in SailfishOS:Chum. Such packages are then principal reason why ignoring the vendor tag when updating with packages from OpenRepos is a "very bad idea"™.
  • All packages in SailfishOS:Chum are built in a fully traceable manner from their source, vastly reducing the risk of malicious software.
  • All packages in SailfishOS:Chum undergo manual approval twice: The first time fundamentally, when a package is accepted into SailfishOS:Chum:Testing, and then each time when a package is submitted to SailfishOS:Chum proper.
• "I consider it a feature and the needed one." It definitely is a feature, but not a required one: Before the introduction of "vendor stickiness" about a decade ago, Linux distributions worked well without it.

After some pondering, I do concur that ignoring the vendor tag when the SailfishOS:Chum GUI app updates packages (implicitly only with ones in the SailfishOS:Chum repository) should be optional, because the current behaviour is well established and desirable for many. Hence I adapted the title and the initial posting accordingly.

[piggz]

I would back the view that the use of vendor stickiness is useful, and designed to cause less issues when updating. If it was made optional, perhaps there should be a dialog/info of packages that would change vendor? It may also be the case that users dont appreciate the concept of a vendor change, so perhaps a description or link out to some docs would be useful?

[rinigus]

For example, Jolla Store could have the same version but with larger release.

For this case the change suggested here would make no difference at all, because the SailfishOS:Chum GUI app does not access the Jolla Store rsp. its repository.

Let me explain then on example: you can have Pure Maps from Chum and Jolla Store. They would have the same version but different release. Let's say Chum one has 3.2.0-1.jolla.1234 and Store has 3.2.0-2. In the store, release was set to 2 for one or another reason. When users will update some package at Chum (not necessarily Pure Maps, but anything else), pkcon in its great wisdom will update all packages it can (we had discussion regarding it already). And, if without vendor tag, Pure Maps will be "updated" to Jolla Store version.

That's a situation, vendor is designed to protect against and it is used by us accordingly.

They want the newest version, wherever it comes from.

No, not really. Pure Maps in Jolla Store is significantly degraded when compared to Chum version. If user has selected a channel, that user should expect that the software updates would come from that channel as well.

Then again, there could be software that is distributed via Jolla Store and preferred by the user. Through vendor tag, we give a choice to the user and respect it.

I hope that my examples illustrated usefulness of vendor tag.

[Olf0]

I hope that my examples illustrated usefulness of vendor tag.

Yes, they do. I missed to take issue #67 fully into account, which was originally reported as Storeman issue #96 by me.

Sorry to have bothered you, sometimes I loose oversight of what I should already know.

⇒ Closing.