[SailfishDevel] Harbour compatibility - including multiple executables in a single RPM

Sat Jun 2 01:05:16 UTC 2018

Fri, 1 Jun 2018 09:53:10 +0100 David Llewellyn-jones:
> On 01/06/18 09:07, rinigus wrote:
>> 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.
> 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.
>
>>      > 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
>>      > (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>).
>>
>>      Just so I'm clear, for your workaround you joined the two code bases at
>>      compile time?
>>
>>
>> Yes, exactly this way
> Thanks; that makes sense. It's a good solution.
>
>>      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 :)
> 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,
While in some cases the rules are clearly understandable,
such as mandating that developers use only external libraries
with known stable API so that applications remain working
in the future.

In other cases I think the rules are detrimental to the overall application
and packaging quality, such as:

- you have to cram everything, including any external dependencies,
  into a single package, which is the direct opposite of good Linux
  distro packaging practices
- no RPM scriptlets are allowed, so code that would run once to handle
   any local data migration and similar tasks will have to run at every
   application start rather than once at package update as on normal
   Linux distros
- Harbour applications still (AFAIK) can't use such basic functionality
   such as assigning custom actions to volume buttons, keeping the
   device screen on or temporarily inhibiting device suspend to keep
   important background tasks running without interruption
- socket activation is no longer allowed, which effectively removed
   OSM Scout Server, the best provider of offline mapping services
   on any mobile platform currently in existence from the Jolla Store
   and thus from many potential users
- applications can be submitted as binary only, there is no option
   to submit application source to be built on trusted build infrastructure,
   so users and store QA have to believe developer the application actually
   is built from the given source (if any) and actually does what the
   developer claims it does

In the end I ended up with two versions of the modRana package,
one that's full featured and goes to OpenRepos and another one
cut down & hacked to hell to pass all the Harbour hoops.

And that's just rule/process induced badness, if we compare Jolla Store
with OpenRepos or some Linux distro repositories on features:

- Jolla Store lacks any web interface, people without a Sailfish OS device
   can't check what apps are available & you can't send people links 
pointing
   to apps in the Jolla Store
- developers get no notification about new comments from users (yes 
really),
   you basically have to keep checking manually in the app, the app is 
also the only way to
   write and reply to app comments
- it's impossible to install an older version of a package from Jolla 
Store (OpenRepos & Linux
   distro repos can generally hold multiple package versions)

>   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.
Yeah, that sounds pretty arbitrary. Restrictions like this should all 
have good reasons
specified in the documentation, or should not be there at all.

>
> Sorry if this sounds ranty; it's not directed at you if it does!
>
> David
Best Wishes
Martin Kolman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.sailfishos.org/pipermail/devel/attachments/20180602/5ab0f26c/attachment.html>