<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body smarttemplateinserted="true">
<div id="smartTemplate4-quoteHeader">Fri, 1 Jun 2018 09:53:10
+0100 David Llewellyn-jones:</div>
<blockquote type="cite"
cite="mid:37cd5cb8-993f-5c96-ca35-e4e4cb336cf4@flypig.co.uk">
<pre wrap="">On 01/06/18 09:07, rinigus wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi David,
> the rules regarding single executable haven't changed, to my knowledge.
I actually can't see anything in the rules that states you can't have
multiple executables, but it is a requirement to pass through the
rpmvalidator. If it's a requirement, I'm thinking it would be helpful to
make this explicit in the FAQ (which is the closest thing I'm aware of
to a stated set of rules).
You are probably right, but I haven't checked the text of the rules
recently. They may "hide" it behind that you are expected to have your
exe be called harbour-something and only that way.
</pre>
</blockquote>
<pre wrap="">
Right, that's the only part that I can find that implies
single-executable, but I wouldn't call it explicit or transparent.
I guess my point - which isn't directed at you of course! - is that it's
important for Jolla to be really clear in the FAQ, because this is the
part you read *before* you start designing the architecture, whereas the
rpmvalidator is only something you can apply after you're already too
far down the road to change it.
</pre>
<blockquote type="cite">
<pre wrap="">
> That particular problem was solved for my case by writing a wrapper and
> called either QML main or the main I wanted to use from Valhalla
> (<a class="moz-txt-link-freetext" href="https://github.com/rinigus/osmscout-server-route/blob/master/src/harbour-osmscout-server-module-route.cpp#L19">https://github.com/rinigus/osmscout-server-route/blob/master/src/harbour-osmscout-server-module-route.cpp#L19</a>
<a class="moz-txt-link-rfc2396E" href="https://github.com/rinigus/osmscout-server-route/blob/master/src/harbour-osmscout-server-module-route.cpp#L19"><https://github.com/rinigus/osmscout-server-route/blob/master/src/harbour-osmscout-server-module-route.cpp#L19></a>).
Just so I'm clear, for your workaround you joined the two code bases at
compile time?
Yes, exactly this way
</pre>
</blockquote>
<pre wrap="">
Thanks; that makes sense. It's a good solution.
</pre>
<blockquote type="cite">
<pre wrap=""> Unfortunately that won't work in my case, because I have my programme
(C++) calling a Perl programme, which then calls another (C-complied)
executable. It's possible using Perl would be reason enough to reject
from Harbour, but one step at a time! The issue of multiple executables
seems more fundamental to me.
> This solution would work, but its a touch harder to maintain. In the
> end, its up to you whether you want to have the app in the harbour or
> not. After all, its your decision. However, I would suggest to consider
> distribution via OpenRepos and not waste too much time for working
> around Harbour rules.
Ultimately, I agree it's much simpler to release through OpenRepos (I'm
already doing this in fact), and I can appreciate the frustration for
you of having to pull your app later. At least you achieved it, even f
just temporarily. Getting something into Harbour is an important life
goal for me ;)
I understand, its a sport in the beginning. There is a simpler solution
- you can always release a fart app for getting into the store :)
</pre>
</blockquote>
<pre wrap="">
Yes, unfortunately "not releasing a fart app" is also one of my life
goals :)
I make light of it, but it's actually more than a sport. I submitted my
first app back in 2014 and I'm still trying. Developers are held back by
Harbour's restrictive policies and lack of support for payment, while
user adoption is held back by lack of apps in the store (or so people
say). Anything that increases the quantity of quality docked apps in the
harbour has to be a good thing.
At the same time, the Harbour rules should represent a checklist of
good-practice for developers,</pre>
</blockquote>
While in some cases the rules are clearly understandable,<br>
such as mandating that developers use only external libraries <br>
with known stable API so that applications remain working<br>
in the future.<br>
<br>
In other cases I think the rules are detrimental to the overall
application <br>
and packaging quality, such as:<br>
<br>
- you have to cram everything, including any external dependencies,<br>
into a single package, which is the direct opposite of good Linux<br>
distro packaging practices<br>
- no RPM scriptlets are allowed, so code that would run once to
handle<br>
any local data migration and similar tasks will have to run at
every<br>
application start rather than once at package update as on normal<br>
Linux distros<br>
- Harbour applications still (AFAIK) can't use such basic
functionality<br>
such as assigning custom actions to volume buttons, keeping the<br>
device screen on or temporarily inhibiting device suspend to keep<br>
important background tasks running without interruption<br>
- socket activation is no longer allowed, which effectively removed<br>
OSM Scout Server, the best provider of offline mapping services<br>
on any mobile platform currently in existence from the Jolla Store<br>
and thus from many potential users<br>
- applications can be submitted as binary only, there is no option<br>
to submit application source to be built on trusted build
infrastructure,<br>
so users and store QA have to believe developer the application
actually<br>
is built from the given source (if any) and actually does what the<br>
developer claims it does<br>
<br>
In the end I ended up with two versions of the modRana package,<br>
one that's full featured and goes to OpenRepos and another one<br>
cut down & hacked to hell to pass all the Harbour hoops.<br>
<br>
And that's just rule/process induced badness, if we compare Jolla
Store<br>
with OpenRepos or some Linux distro repositories on features:<br>
<br>
- Jolla Store lacks any web interface, people without a Sailfish OS
device<br>
can't check what apps are available & you can't send people
links pointing<br>
to apps in the Jolla Store<br>
- developers get no notification about new comments from users (yes
really), <br>
you basically have to keep checking manually in the app, the app
is also the only way to<br>
write and reply to app comments<br>
- it's impossible to install an older version of a package from
Jolla Store (OpenRepos & Linux<br>
distro repos can generally hold multiple package versions)<br>
<br>
<blockquote type="cite"
cite="mid:37cd5cb8-993f-5c96-ca35-e4e4cb336cf4@flypig.co.uk">
<pre wrap=""> so I like to follow the guidelines if I
can, even if my app will never be accepted. I assume there's a good
reason for all of the rules :/ I'm not sure what the reason for
restricting multiple binaries is, though.</pre>
</blockquote>
Yeah, that sounds pretty arbitrary. Restrictions like this should
all have good reasons<br>
specified in the documentation, or should not be there at all.<br>
<br>
<blockquote type="cite"
cite="mid:37cd5cb8-993f-5c96-ca35-e4e4cb336cf4@flypig.co.uk">
<pre wrap="">
Sorry if this sounds ranty; it's not directed at you if it does!
David
</pre>
</blockquote>
Best Wishes<br>
Martin Kolman<br>
<br>
<div id="smartTemplate4-template">
<p> </p>
</div>
</body>
</html>