So I read this announcement which is all glee about something called AppStream. I have checked their homepage and I have also perused their documentation. However, none of that has provided a clear, concise answer to my question:
What problem does AppStream solve?
Would I be mistaken in saying it appears to be trying to transpose the “market” metaphor from Android and Apple OS (whatever it’s called) products into the Linux arena?
I understand that other distros may have less than optimal package managers, but I do not believe that to be the case with Yast2, so in particular:
What problem does AppStream solve for OpenSUSE users?
Knowledgeable answers would be most welcome. Those from anyone involved with this are particularly appreciated.
Hi
None, it’s a feature (not sure about that though)… https://wiki.gnome.org/Design/Apps/Software uses it (not sure of the other DE’s equiv), but for some folks it would give indications of how popular an application is etc.
I would put it along the lines of the long forgotten hardware information database folks could press a button and add their system(s) to. A marketing tool to collect data ($$$??) across the various distribution for what is hot and what is not…
> WHAT PROBLEM DOES APPSTREAM SOLVE FOR OPENSUSE USERS?
> Knowledgeable answers would be most welcome. Those from anyone involved
> with this are particularly appreciated.
>
> Thanks in advance.
>
>
I don’t know if this helps.
The existing Ubuntu Application Center fits the perceived need and is an established and stable project.
With insightful star ratings, carefully thought out reviews and all. A help to “new users” and “average users” who permanently are confused and frustrated. Only software centers, with “feedback”, can save this situation. Will suggest what to click on based on “recommendations”, “featured”, “reviews”. “Social media” is also mentioned because relevant. Retweet. Zeitgeist tracks all events or why even bother?
If you think Yast does same job you need to put click click consumer hat on and visit som “app stores” or market places. This is not just a way of installing stuff but about the “experience”. Even clicking “Install” button is being discussed, may be “Launch” sounds like hmm easier? Like “app” vs. “program”.
As Gnome Software Center says on first run, next to shopping bag icon, “Lets go shopping”.
May be they should remove “root” term as it will lower barrier to entry hence must be good?
They do talk of “add a shared linux ecosystem repositories” but what mind is full of it not same as realities. AppStream will probably just be a combo of providing and slurping data. What to do with it is up to distributions. May be openSUSE will settle for tracking and screenshot feature while “PAY ME as I want money and just spend $$$ to get friggin featured!!!” distros or app-makers! will go to the max.
That wikipedia definition is probably simplest, most fundamental and comprehensive.
Although you can get lost in the trees considering the effects on individual distros/OS, it’s pretty basic…
A metadata repository that describes installation packages.
This is especially important to anyone who has run into an app built only for one distro (like Android) and wondered how to get that app to run on their own distro or device (like openSUSE or iOS). It’s probably largely based on the idea that there are many libraries that are common across distros but named differently and installed into different locations which is why for instance we openSUSE have the “alien” app.
I wouldn’t expect that just any app can easily and quickly be built into an AppStream deployment/install, the metadata has to be created.
Note the similarity to what OBS delivers… With a common source, you can build target install packages for priactically every other distro (but last I checked didn’t support mobile OS like Android and iOS).
This has nothing to do with installing packages meant for other distributions, and nothing at all with differently named libraries neither.
Appstream basically just provides more detailed description of Applications (as opposed to packages), and it abstracts away from single packages. It is concerned about listing and installing applications, not which packages they consist of or how they are named.
Or to put it slightly different: Appstream lets the user install an application without having to know how the necessary packages are named or which are needed exactly.
I wouldn’t expect that just any app can easily and quickly be built into an AppStream deployment/install, the metadata has to be created.
Many applications in openSUSE, at least based on GNOME or KDE, do come with Appstream metadata already (most of the time it’s included upstream).
And zypper and the buildservice tools support it as well.
Try to run:
zypper se -t application
This shows all Appstream applications available in your repos…
Note the similarity to what OBS delivers… With a common source, you can build target install packages for priactically every other distro (but last I checked didn’t support mobile OS like Android and iOS).
No. OBS delivers packages. But Appstream describes “applications”.
I am corrected, but not exactly.
After reading more examples and uses of AppStream, yes it appears that package description is not a central feature although may be described in the metadata.
After inspecting uses by Amazon, Symantec and Splunk, it appears to be at its core an app distribution, management and updating platform. In the course of doing this, additional specifics might be managed… So yes, it’s also possible that its metadata can be found upstream in any number of apps which might have been managed by AppStream before making its way into other distribution channels. It can also be used to manage distribution of its core before modified for device-specific installs.
Actually I just wanted to clarify some things according to my understanding, not correct you.
After reading more examples and uses of AppStream, yes it appears that package description is not a central feature although may be described in the metadata.
AIUI, package description is not a feature at all.
That’s a feature of rpm already anyway.
It does allow to install applications (or other stuff) by their name, without knowing how exactly the package is called in a particular distribution though.
After inspecting uses by Amazon, Symantec and Splunk, it appears to be at its core an app distribution, management and updating platform. In the course of doing this, additional specifics might be managed… So yes, it’s also possible that its metadata can be found upstream in any number of apps which might have been managed by AppStream before making its way into other distribution channels. It can also be used to manage distribution of its core before modified for device-specific installs.
Again, Appstream only consists of additional metadata that describes applications, to make it (supposedly) easier to install applications you’re interested in. It is added onto the existing means.
Of course you can build your own distribution channels using Appstream metadata.
But that’s not what Appstream itself is about. Appstream is just about that metadata.
And it’s also not Appstream that manages the metadata. The applications that want to be found in so-called “Software Centers” (like gnome-software e.g.) have to provide it (or the distribution has to provide it for them). In openSUSE it is part of the standard repo meta-data, like the package descriptions and dependencies.
Appstream basically is just a standard how to provide that application metadata.
RedHat people have been hacking on something similar http://blog.mlich.cz/2015/04/web-software-center-for-fedora/ But better because web based so kept out of distro. Can more easily be ignored and also fine tuned for those who do love it - bigger and more stars, more “top” lists and such.
May be openSUSE should get the same idea? Yast has trouble just understanding concept of a hyperlink. They are supposed to be clickable.
Some time ago I ran in to a thread on a Fedora mailing list where one dev. suggested they got an app thingy “similar to Ubuntu”, with ratings and all. Yumex does not cut it and is 3rd party. Did not go down too well so more mind share for idea must have been won since then. Another side effect of mobile mania perhaps - and Gnome Software
> Try to run:
>
> Code:
> --------------------
> zypper se -t application
> --------------------
>
> This shows all Appstream applications available in your repos…
cer@minas-tirith:~> zypper se -t application
Unknown package type 'application'.
cer@minas-tirith:~>
[QUOTE=robin_listas;2707191]On 2015-04-19 00:36, kerijan2003 wrote:
>
> This question is probably best asked in the Chit-Chat forum.
Absolutely…
There are way too many forums already. It just makes it difficult to know where to head off to should one be looking for some information, or even try to help out by answering a few help requests. Not to mention all the arguments started about whether something is in the right forum or not.
From the explanations given, I am led to understand that it is just a convention for some extra metadata about packages, which applications may choose to consume (or not)?
On 2015-05-13 00:46, licehunter wrote:
>
>>> robin_listas;2707191 Wrote:
>>> On 2015-04-19 00:36, kerijan2003 wrote:
>>>>
>>>> This question is probably best asked in the Chit-Chat forum.
>>>
>>> Absolutely…
>>>>>
>>
>> There are way too many forums already. It just makes it difficult to
>> know where to head off to should one be looking for some information,
>> or even try to help out by answering a few help requests. Not to
>> mention all the arguments started about whether something is in the
>> right forum or not.
Which is why we suggested you where to ask.
You just have to request a moderator to move your post, using the
triangle button below.
From what I researched before,
Most basicly it’s app version control, it tracks versions of an app’s files (if used to support an app). This is one of the most nettlesome and oftentimes costly aspects of code writing… If you intend to maintain the app, how do you track the status/version of the app or its parts and determine what is to be updated? There are several concepts/approaches on how to do this, and it can get more complicated if several updates are skipped, are you really going to require every intermediate (and obsolesced) update to be installed as well?
So, from a code developer’s perspective, it solves an important problem relating to code maintenance.
But, one of the implementations I listed has little to do with code maintenance. That solution actually was using appstream to manage the versions of its distributed database content which is an interesting and innovative way to apply a core functionality in a very different scenario.
So, it is a convention (commonly accepted format and methods) but a lot more.
That’s why in my description I elevated appstream to a type of platform.
???
I think you are talking about something completely different…
The official AppStream specification and documentation (AppStream | AppStream 1.0) doesn’t mention anything about code-writing or version tracking at all.
Here’s the “Abstract”, btw:
AppStream is a cross-distro effort for enhancing the way we interact with the software repositories provided by the distribution by standardizing sets of additional metadata.
AppStream provides the foundation to build software-center applications. It additionally provides specifications for things like an unified software metadata database, screenshot services and various other things needed to create user-friendly application-centers for (Linux) distributions.
