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
_______________________________________________
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
