[SailfishDevel] Jolla Harbour. Application names conflicts

[Thomas Perl]

Hi,

On 2013-11-12 20:40, Semuonov Basil wrote:
> Case 1 - Titles are the same:
> Dev1 submits application called "Trains Europe" about history of 
> europe trains with binary "trains_1.0.0_armv7hl.rpm"
> Dev2 submits application called "Trains Europe" about online timetable 
> for train transport called "trainseurope_1.0.0_armv7hl.rpm".

That should not be a problem and is just a visual thing. Ideally, the 
two different apps have a different icon, and can be distinguished that 
way. That's by the way also the case for the Angry Birds apps on Android 
(all icons are called "Angry Birds" in the app selector, but the icons 
show which game it is).

> Case 2 - Binary names are the same:
> Dev1 submits application called "Trains Europe History" about history 
> of europe trains with binary "trainseurope_1.0.0_armv7hl.rpm"
> Dev2 submits application called "Trains Europe Timetable" about online 
> timetable for train transport called "trainseurope_1.0.0_armv7hl.rpm".

That will not be possible by store intake rules - there can only be one 
package name and that has to be unique. The one who submits second will 
have to rename their package. That's also why it's suggested to have a 
package name in reverse-domain notation on a domain you have, e.g. 
"org.ilovetrains.timetable.sailfish_1.0.0_armv7hl.rpm" (and have all 
files in there similary namespaced - yes, that means 
/usr/bin/org.ilovetrains.timetable.sailfish and 
org.ilovetrains.timetable.sailfish.desktop).

> Case 3 - Exact same package (opensource) from developers:
> Dev1 submits application called "Trains Europe Timetable" about online 
> timetable for train transport for France and Germany with binary 
> "trainseurope_1.5.0_armv7hl.rpm"
> Dev2 submits application called "Trains Europe Timetable" about online 
> timetable for train transport for France and Italy called 
> "trainseurope_1.3.7_armv7hl.rpm".
> Both packages are based on some opensource application but dev 
> implement own updates to package..

Again, in this case, this won't be possible as it's again the same 
binary name by different packages in the store.

If you're forking an open source application and publish your own 
version, it's a good idea to rename it, ideally in such a way that it's 
not confusing with the original version. This means not only renaming 
the package name, but also the binary name in the package (that's 
/usr/bin/<name>, /usr/share/<name>, the icon an .desktop file name, 
etc.. - no files in both packages must collide - this then also allows 
for installing both apps simultaneously). Be creative - to continue with 
the train theme, the French-German train table app could be named "Le 
Zug Horaires". Or come up with a maritime-themed name, "traindock", 
"trainbow" (yay! both train and bow as well as T-rainbow whatever that 
is), "railferry", etc.. - you get the idea.

> The 3rd case is most valuable since, lots of apps are being ported and 
> submitted to harbour not by primary devs, but by support teams.

Ideally if people are doing only a few contributions, they should think 
about submitting their changes upstream first (or the the respective 
currently-active downstream packaging team) before forking and uploading 
their own version, even if that would be tempting and sometimes easier. 
It's always better for the user (even if more work for the developer) to 
have a single app with feature X and Y well integrated than two forks of 
the same app, in which one has only feature X, and the other only has 
feature Y. Add to that that they'd have the same or a similar name, and 
users will have a hard time figuring things out.

HTH :)
thp