Dear Packagers,
Since recently, openSUSE Tumbleweed has a new generator for AppStream Metadata, which processes all RPMs during the Repository creation.
What uses AppStream Metadata **************************** The metadata describes what 'Applications' can be found in a repository, rather than what packages. As such, it's obvious target is 'Software Centers'. At this moment, GNOME Software is the only Software center shipped in openSUSE Tumbleweed that makes use of this metadata. But I heard of a KDE Software Center in 'the works' as well. So this is not GNOME Thing.
What does my package have to provide to be shown in the Software Center *********************************************************************** AS a bare minimum, the package containing the application must have a .desktop file (sounds almost obvious). If nothing else, the .destop file must have a Name, Generic Name and Comment field to describe the app at a bare minimum.
The package must contain an icon, of at least 32x32 pxels (64x64 preferred). The icon must be installed below /usr/share/icons/ or /usr/share/pixmaps. It must not be referenced from the .desktop file by an absolute path outside these locations. Also, it must be a real file, not a symlink to a file outside /usr/share/{icons,pixmaps}. The same is also required by another project, called 'xdg-app', which aims at containerizing applications (using ostree and nspawn). Icons must be accessible in the defined locations.
Optional: The applicstion can present itself with much better information in the Software Center (incl. Screenshots, work in progress for openSUSE). In this case, the package containing the .desktop file has to also install a .appdata.xml file. The specification for the appdata format can be found at http://people.freedesktop.org/~hughsient/appdata/
Which applications do currently show up inthe Software Center ************************************************************* As a human aid, the metadata generator also outputs a HTML File, which can be found at http://download.opensuse.org/tumbleweed/repo/oss/suse/setup/descr/appdata.ht...
My package does not show in the SC ********************************** Ensure all the pre-requisites are met. You can also check http://download.opensuse.org/tumbleweed/repo/oss/suse/setup/descr/appdata-fa... which generally contains information of a 'veto', why a package was skipped to be added to the AppStream metadata. Most common one is "No 'Comment' in desktop or in AppData"
Is it mandatory for my package to provide all this ************************************************** At this moment it is not mandated, but is surely a good thing for the users. Packages are fine from a technical PoV, but they are not what a user should have to care for. Allowing to work in an 'Application' view is more helpful in the long run.
Should you have any questions, simply ask,
Cheers, Dominique
On Monday 30 March 2015 11.17:03 Dominique Leuenberger / DimStar wrote:
Dear Packagers,
Since recently, openSUSE Tumbleweed has a new generator for AppStream Metadata, which processes all RPMs during the Repository creation.
What uses AppStream Metadata
The metadata describes what 'Applications' can be found in a repository, rather than what packages. As such, it's obvious target is 'Software Centers'. At this moment, GNOME Software is the only Software center shipped in openSUSE Tumbleweed that makes use of this metadata. But I heard of a KDE Software Center in 'the works' as well. So this is not GNOME Thing.
What does my package have to provide to be shown in the Software Center
AS a bare minimum, the package containing the application must have a .desktop file (sounds almost obvious). If nothing else, the .destop file must have a Name, Generic Name and Comment field to describe the app at a bare minimum.
The package must contain an icon, of at least 32x32 pxels (64x64 preferred). The icon must be installed below /usr/share/icons/ or /usr/share/pixmaps. It must not be referenced from the .desktop file by an absolute path outside these locations. Also, it must be a real file, not a symlink to a file outside /usr/share/{icons,pixmaps}. The same is also required by another project, called 'xdg-app', which aims at containerizing applications (using ostree and nspawn). Icons must be accessible in the defined locations.
Optional: The applicstion can present itself with much better information in the Software Center (incl. Screenshots, work in progress for openSUSE). In this case, the package containing the .desktop file has to also install a .appdata.xml file. The specification for the appdata format can be found at http://people.freedesktop.org/~hughsient/appdata/
Which applications do currently show up inthe Software Center
As a human aid, the metadata generator also outputs a HTML File, which can be found at http://download.opensuse.org/tumbleweed/repo/oss/suse/setup/descr/appdata.ht...
My package does not show in the SC
Ensure all the pre-requisites are met. You can also check http://download.opensuse.org/tumbleweed/repo/oss/suse/setup/descr/appdata-fa... which generally contains information of a 'veto', why a package was skipped to be added to the AppStream metadata. Most common one is "No 'Comment' in desktop or in AppData"
Is it mandatory for my package to provide all this
At this moment it is not mandated, but is surely a good thing for the users. Packages are fine from a technical PoV, but they are not what a user should have to care for. Allowing to work in an 'Application' view is more helpful in the long run.
Should you have any questions, simply ask,
Cheers, Dominique
Hi Dominique, first thanks for your deep explanation.
For my full understanding, I still need some clarifrcation :
We have ton's of global application that can be split into several rpm. Then how it should be handled ... a specific rpm presenting just the application with all requires sub rpm?
What about typical server package (seems strange to have a screenshot of a database module for example) Then if I create a desktop file for collectd then it will appear in the user menu. Or this kind of application/service have nothing to do with user interaction most of the time.
Thanks for your comments
On Mon, 2015-03-30 at 13:57 +0200, Bruno Friedmann wrote:
For my full understanding, I still need some clarifrcation :
We have ton's of global application that can be split into several rpm. Then how it should be handled ... a specific rpm presenting just the application with all requires sub rpm?
The guideline there is: if it makes sense to have one part / .desktop file available to the user without the others, then preferably it should be split. We (GNOME Team) for example split out eog-plugins in like 10 sub packages (they don't have a .desktop file, but provide a meta file to declare to GNOME Software that the packages extend eog's functionality further... that can be introduced later though)
What about typical server package (seems strange to have a screenshot of a database module for example) Then if I create a desktop file for collectd then it will appear in the user menu. Or this kind of application/service have nothing to do with user interaction most of the time.
I'd not consider a 'server' an 'end user targeted application' that makes any sense to be presented in a Software Center. Stuff that does not have a .desktop file, should not receive one and should also not go to the Software Centers (in short: if I can't start it and interact with it, it's no application).
Thanks for your comments
Does that clarify things?
Cheers, Dominique
On Monday 30 March 2015 15.05:41 Dominique Leuenberger / DimStar wrote:
Does that clarify things?
Yeap, the definition is clear.
I'm just curious then about the utility of that kind of AppStore compared to plain repository. And the definition of what is an application or not :-)
On Tue, 31 Mar 2015 07:15, Bruno Friedmann wrote:
On Monday 30 March 2015 15.05:41 Dominique Leuenberger / DimStar wrote:
Does that clarify things?
Yeap, the definition is clear.
I'm just curious then about the utility of that kind of AppStore compared to plain repository. And the definition of what is an application or not :-)
First, thanks to DimStar for the intro, great work.
Second, to Bruno, (with tongue in cheek) about "AppStore", haven't you heared yet of the 'great app shops' of Apple (iStore) and Android ?
Seems like Microsoft came to the same conclusion, and started their own. Now, us poor Linux users can not be let be without such a "marvelous" option?
More serious, when applied with sandboxing / jailing, this is the "colourful clicky" option for the uninformed newbies to install the wanted apps, without bringing chaos, insecurity, and destroyed maintainablility (updates) to the base system.
Even as an old-school UNIX user, I see the positives in the "AppStore" model, in the face of the wide-spread already there usage, Linux as OS can profit from this.
- Yamaban.
On Tuesday 31 March 2015 07.36:36 Yamaban wrote:
On Tue, 31 Mar 2015 07:15, Bruno Friedmann wrote:
On Monday 30 March 2015 15.05:41 Dominique Leuenberger / DimStar wrote:
Does that clarify things?
Yeap, the definition is clear.
I'm just curious then about the utility of that kind of AppStore compared to plain repository. And the definition of what is an application or not :-)
First, thanks to DimStar for the intro, great work.
Second, to Bruno, (with tongue in cheek) about "AppStore", haven't you heared yet of the 'great app shops' of Apple (iStore) and Android ?
heared yes, never need them, Hate the Jolla store messy as possible like any others
Seems like Microsoft came to the same conclusion, and started their own. Now, us poor Linux users can not be let be without such a "marvelous" option?
Well, if I was the only one to decide :-)
More serious, when applied with sandboxing / jailing, this is the "colourful clicky" option for the uninformed newbies to install the wanted apps, without bringing chaos, insecurity, and destroyed maintainablility (updates) to the base system.
Even as an old-school UNIX user, I see the positives in the "AppStore" model, in the face of the wide-spread already there usage, Linux as OS can profit from this.
Then you never see what a end-user is able to do to its device in less than 3 months.
- Yamaban.
When we still have users having +64 repo activated and ask for help :-)))
I can help certainly, but in those case it will not be for free....
-
Bruno Friedmann -
Dominique Leuenberger / DimStar -
Yamaban