Notices

I am confused . Your answer seems to be contradictory.

If I get you right,

• "Does it need to be SFOS-version specific?" NO
• "Isn't it an overkill to make [a patch] depend on a specific version of SFOS?" NO
• "Will pkcon/zypper not work it out in such a case?" NO

Clearly, a negative answer to items 2 and 3 contradicts a negative answer to item 1.

That's kinda obvious. But not what I was asking. I was asking about indirect dependencies. Is it absolutely necessary to spell out every brick or go out full-on desperate and specify an OS version dependency? Or can I just specify a dependency on a given package that I know includes all the bricks?

That way, if that specific package does not change on an OS update, then I am guaranteed that all the dependencies are still satisfied and my package does not need to do anything. Conversely, if the package I depend on changes without an OS update, then I know I need to update my package.

It's pretty common for package managers to make a hard dependency on the OS major version at times. Some programs needn't do this (e.g., Tidings has been unreleased for a long time and yet it "survived" many major OS upgrades) but others may benefit from this.
Depending on a specific package because you know it will have all the dependencies may not be possible on major OS upgrades as the repository may have changed and that package may not be there any more. Moreover, if you're a developer, it is simpler to set a baseline and just state that in your application - e.g., a SFOS 3.4 developer will probably not know what SFOS 1.0 had bundled, so it's just simpler to make the program compatible for a current version.
What you describe is a pattern used in OS's/distributions that support rolling upgrades, and even in those cases there are certain states where you won't be able to upgrade any more, one of the most popular reasons being that packages simply change or disappear from the repository. In practice, if you forget to upgrade such OS's/distributions for ten years, don't expect that the package manager will happily bring you to the present time.

Not AFAICS.

You do!

Thank you so much.
I will add some comment there - but not tonight, it's been a long day, I'm just sortof winding down here on TMO...

Neither is "absolutely necessary".
While "spelling out" is the sensible way in general, on SFOS that basically makes no difference.

Yes, you can.
E.g., on a version of sailfish-version.

P.S.: Man, you are asking strange questions, loaded with assumptions. Plus structurally always "Is A or B or C?". As most of these do not hold true, the answer is usually "no", "neither" or "none".

Am I? I thought I was asking pretty obvious question to eliminate assumptions!
And, for some strange reason, I am still not getting a straightforward answer

But OK, let's make assumptions explicit.

This is how I see it (simplified, with an explicit assumption that everyone understands that each library, application etc may have multiple versions):



My original question was, "isn't Openrepos clever enough to offer multiple versions and let your device pick the one matching your setup?"

(That is, assuming one uses a proper, rather than lazy dependency definition as per the diagram above.)

Which is not helpful, because some of these assumptions seem to be wrong ones, hence the whole diagram does not make much sense to me.

Look, all these things are publicly documented: Tools, typical workflows, and most importantly, how people practically use it. Plus what the package-resolver (e.g. libzypp) does on your device.
RTFMs and take look at this stuff, in the web (Openrepos.net, Git{hub|lab}.com) and on your device in practice.

See, it is the same here, once again:
The answer is "Yes".
Structurally an concatenation of two questions (here: per "and", instead of "or"), both spiced with wrong assumptions. Negating one of the concatenated questions makes it hard to correctly deduct the overall answer to the question logically, and almost impossible to decode this answer.
Thus this answer very likely (again) does not provide what you wanted to know.

Q1, "isn't Openrepos clever enough to offer multiple versions": Yes, it is not!
- What do you mean to address with "Openrepos": The site <openrepos.net> (spacial), the Openrepos-webfrontend (technical), something else?
- An RPM-repository (maybe you meant that, i.e. "something else" above) is not "clever", it is a directory (tree) published via http(s). It "offers" whatever you put into these directories.

Q2, "let your device pick the one matching your setup?": Yes, dependency resolution is performed by the package resolver locally; AFAIK (at least for rpm, libzypp, dpkg and any tools based on them, as pkcon, zypper, yum, apt etc.) always and solely.


P.S.: Following the three links I provided in my original reply to your original question, might be helpful for you.

P.P.S.:IMO, we shall end this sub-thread here, it is off-topic by far (Q&A for packaging basics).

Which is exactly why making assumptions explicit is helpful (not just in this discussion, but always!).
It clarifies where the two parties come from different angles and identifies the points that may need clarification.

I am sure I could find an answer to everything, if I could afford to devote years of studying and research. All I wanted was a simple, straightforward, "YES" or "NO" answer. If there isn't one, all I wanted was someone to say so. A single post would have done. Instead, we've had two pages of discussions going nowhere.

There you go again. That "answer" is absolutely useless to me. "Yes" and "no" are exact opposites. They are mutually exclusive. It's either-or, it cannot be both.

<snip the rest of your response that, YET AGAIN, did not answer my question>

I give up. It is all off topic anyway. Apologies to rinigus for accidentally hijacking the thread.

Maps updated and uploaded to modRana server, ready for distribution.