Active Topics
-
Is there a section to talk about Java ME? Apps, etc. (0)
to General by Kalatti - 2 days, 6 hrs ago -
Extra softwares in Sailfish using CLI, repositories, etc (117)
to SailfishOS by nieldk - 4 days, 3 hrs ago -
Firefox with Leste (6)
to Maemo 7 / Leste by teroyk - 5 days ago - more...
rinigus |
2020-11-22
, 11:52
|
|
Posts: 1,414 |
Thanked: 7,547 times |
Joined on Aug 2016
@ Estonia
|
#811
|
Originally Posted by nonsuch
I presume you had an old version and Pure Maps was activating it via systemd sockets. Any tips on limiting the rate are welcome - corresponding PR as well!
 |
|
2020-11-22
, 13:41
|
|
Posts: 304 |
Thanked: 1,246 times |
Joined on Aug 2015
|
#812
|
Originally Posted by pichlo
<ot>
I have always been wondering: isn't Openrepos clever enough to offer multiple versions and let your device pick the one matching your setup? Why do I bother defining version dependencies in my packages?
</ot>
Originally Posted by rinigus
... and all what is needed.
pkcon || zypper are clever enough - [...]
Originally Posted by rinigus
... which are not needed, anyway.
It's just we don't have repos specific to SFOS versions.
For example, the recent Storeman and crypto-sdcard RPMs are provided in SFOS-version specific releases in a single RPM-repository.
I documented how to handle this (primarily for myself) in crypto-sdcard's "Release version format, RPM dependencies and Git workflow". Suggestions, enhancements, constructive criticism, etc. are welcome, as always.
Last edited by olf; 2020-11-22 at 14:51.
| The Following 4 Users Say Thank You to olf For This Useful Post: | ||
 |
|
2020-11-22
, 23:06
|
|
Posts: 6,445 |
Thanked: 20,981 times |
Joined on Sep 2012
@ UK
|
#813
|
Sorry a naive question from an old geezer with only a shallow understanding of Linux and its distribution systems.
Does it need to be SFOS-version specific? If let's say a patch updates let's say the SMS app version x.yy.zzz, isn't it a bit of an overkill to make it depend on a specific version of SFOS, rather than, more logically, on a specific version of the SMS app? Will pkcon/zypper not work it out in such a case?
Does it need to be SFOS-version specific? If let's say a patch updates let's say the SMS app version x.yy.zzz, isn't it a bit of an overkill to make it depend on a specific version of SFOS, rather than, more logically, on a specific version of the SMS app? Will pkcon/zypper not work it out in such a case?
__________________
Русский военный корабль, иди нахуй!
Русский военный корабль, иди нахуй!
 |
|
2020-11-23
, 07:53
|
|
Posts: 584 |
Thanked: 1,550 times |
Joined on Sep 2019
|
#814
|
Originally Posted by rinigus
Strangely I don't think Pure Maps was running at that moment, I had only just booted the phone.
I presume you had an old version and Pure Maps was activating it via systemd sockets.
I gather from your comment that this is a known issue, maybe it was already mentioned elsewhere.
Any tips on limiting the rate are welcome - corresponding PR as well!
Be that as it may, ~50 times a second seems too much, but otoh there might be a good reason for that.
|
|
2020-11-23
, 16:11
|
|
Posts: 304 |
Thanked: 1,246 times |
Joined on Aug 2015
|
#815
|
Originally Posted by pichlo
3 * No
Sorry a naive question from an old geezer with only a shallow understanding of Linux and its distribution systems.
Does it need to be SFOS-version specific? If let's say a patch updates let's say the SMS app version x.yy.zzz, isn't it a bit of an overkill to make it depend on a specific version of SFOS, rather than, more logically, on a specific version of the SMS app? Will pkcon/zypper not work it out in such a case?
(10chars)
|
|
2020-11-23
, 16:35
|
|
Posts: 1,414 |
Thanked: 7,547 times |
Joined on Aug 2016
@ Estonia
|
#816
|
@olf: I must say it is fast becoming rather elaborate in terms of trying to support multiple SFOS versions with several packages. I prefer to offload this to the users and provide such support using OBS repos. There is limited time that has to be taken into account and, in this context, I prefer to distribute the workload instead of piling it all on myself.
@nonsuch: something has to access it to make it happen. It could be any other client that you could have been running (modRana, sports app). Don't know what else could it be. I guess that you had somehow a server version installed which could not be launched. Why, no idea. And systemd tried to launch it - many times. Alternative is that socket activation script was left behind after uninstall. But I would expect systemd to check for availability of executable before starting it.
Please file it as an issue, so I would remember to look into it.
@nonsuch: something has to access it to make it happen. It could be any other client that you could have been running (modRana, sports app). Don't know what else could it be. I guess that you had somehow a server version installed which could not be launched. Why, no idea. And systemd tried to launch it - many times. Alternative is that socket activation script was left behind after uninstall. But I would expect systemd to check for availability of executable before starting it.
Please file it as an issue, so I would remember to look into it.
|
|
2020-11-23
, 17:20
|
|
Posts: 728 |
Thanked: 1,217 times |
Joined on Oct 2011
|
#817
|
Originally Posted by pichlo
Just to give you a bit more context: each piece of software will probably have dependencies and certain requirements (like syscall availability and such), hence each OS/distribution will package such software according to what is available for each OS/distribution.
Does it need to be SFOS-version specific? If let's say a patch updates let's say the SMS app version x.yy.zzz, isn't it a bit of an overkill to make it depend on a specific version of SFOS, rather than, more logically, on a specific version of the SMS app? Will pkcon/zypper not work it out in such a case?
You are right that if the SMS app changes "a != null" for "null != a", it will not affect those dependencies/requirements, and thus all packagers will find it trivial to update it; however, if an upgrade now requires the availability of e.g., the library to access sqlite databases, each OS/distro will have to adjust accordingly. OS2/Warp (*wink* *wink*) would find it probably impossible, while others will have it provided already and perhaps something like Gentoo Linux will just add a build dependency.
So, it isn't possible to do what you ask unless everybody agrees on a ubiquitous packaging system that does all this for you and works everywhere. I could quote a couple of examples where this "kind of" works at a generic level, but it will a) spark a lot of debate and b) will be very off topic.
Lastly, the examples above (dependencies/sys requirements) don't cover everything that is to be taken into account, there are a lot more things
| The Following 3 Users Say Thank You to ggabriel For This Useful Post: | ||
|
|
2020-11-23
, 19:38
|
|
Posts: 1,414 |
Thanked: 7,547 times |
Joined on Aug 2016
@ Estonia
|
#818
|
@nonsuch: I have opened an issue https://github.com/rinigus/osmscout-server/issues/343
Re dependencies: fortunately, RPM SPEC deps are frequently detected automatically. So, large part of it is done for us. But to support multiple SFOS version from single repo, I would have to have all RPMs with unique names and ensure that they don't clash (sometimes same RPM can be installed in multiple SFOS versions).
Re dependencies: fortunately, RPM SPEC deps are frequently detected automatically. So, large part of it is done for us. But to support multiple SFOS version from single repo, I would have to have all RPMs with unique names and ensure that they don't clash (sometimes same RPM can be installed in multiple SFOS versions).
|
|
2020-11-23
, 19:42
|
|
Posts: 304 |
Thanked: 1,246 times |
Joined on Aug 2015
|
#819
|
Originally Posted by rinigus
That is well understandable and IMO reasonable.
@olf: I must say it is fast becoming rather elaborate in terms of trying to support multiple SFOS versions with several packages. I prefer to offload this to the users and provide such support using OBS repos. There is limited time that has to be taken into account and, in this context, I prefer to distribute the workload instead of piling it all on myself.
I just wanted to point out, that it is technically feasible (which was @pichlo's original question), used in practice at Openrepos, and does not need multiple RPM-repositories.
Last edited by olf; 2020-11-23 at 22:19.
| The Following 4 Users Say Thank You to olf For This Useful Post: | ||
|
|
2020-11-23
, 20:05
|
|
Posts: 1,414 |
Thanked: 7,547 times |
Joined on Aug 2016
@ Estonia
|
#820
|
Originally Posted by olf
It was me who had an impression that you need multiple repos. Turned out to be wrong
That is well understandable and IMO reasonable.
I just wanted to point out, that it is technically feasible (which was @pichlo's question, IIRC), used in practice at Openrepos, and does not need multiple RPM-repositories.
. Thanks for educating!
| The Following 3 Users Say Thank You to rinigus For This Useful Post: | ||
 |
| Tags |
| geocoder, linux, offline maps, router, sailfish os, tiles |
«
Previous Thread
|
Next Thread
»
|
All times are GMT. The time now is 09:35.