Introducing AppStream, Multi-Distro App Framework

[deanjo]

I was mildly excited reading this until I read the dreaded word "PackageKit". There's a reason I stay away from PackageKit like the plague and just use yum from cli (actually I'd probably use yum anyway even if PackageKit didn't bring up really bad memories because there are some things I just prefer doing from cli even if there is an excellent GUI). Then again I haven't actually given PackageKit a shot in a really long time so maybe it's not horrible anymore.

Well in all fairness it isn't so much that packagekit is broke, nor is it the case that the package management in a distro is broke. Where a majority of the breakage occurs is in the "glue" that binds the two together. When there is an update to a package manager, all to often that bind is broken and that is when issues occur and it happens a lot across multiple distros.

[quintesse]

Basically

If I understand this correctly basically what this would allow you to do is say "Wow, FooBar is an excellent app!" and people would be able to find it no matter what distro they're using. The could even provide a link that will work on all the distros that support this system.

It does NOT mean that the packages will be the same or that they will even have the same name or the same dependencies. (I imagine for example that the problem would still exist with somebody, let's say, asking "What's the best player for MP3 files?" and somebody giving a link to Rhytmbox which under Fedora does not include the necessary codec for MP3s.

[przemoli]

I thing AppStream targeted at UX will help desktop Linux. It will help users. It will create common UI/UX among many distro, and it will be easier to merge it will initiative targeted at package/app creators/devs if|when such occur.

It will also erase one more minus stated against linux, different UX among many distros for such common activity like app managing.

So I see thing that will be bit better, and no that will loose on this idea.

[meklu]

I think they could make some tarball standard for third party installers that'd install into /opt.

[przemoli]

And it will enable app-centric distro-independet community of users, sharing meta-data like rating, screenshots, comments, etc.

[TwistedLincoln]

I'm not a fan of this at all. First, I see no use in user comments, ratings and the like being part of a software installation app. Those features would be fine on a website, which in conjunction with something like a distro-neutral version of apt-url would enable the same functionality.

And having a cross-distro installation app causes several issues:

1) It will have to be used alongside a more traditional repository system (like one uses with Synaptic). Since each distro requires different library verisions, etc to funciton properly, not everything can be just dropped into another distro. So while this would be fine for things like installing games, it wouldn't do much good for installing development libraries.

2) Distros with strict Free Software policies could be contaminated by non-free software. Since the software selection would be the same across distros, political issues could cause problems.

3) As drafted, it appears the blueprint for this new system will require internet access (which makes sense if it is integrating social review funcitons). We shouldn't be encouraging users to be dependent on 3rd party services in order to use their system. With apt/rpm, you can easily host your own repository on your local machine or internal server. Will the same be true of AppStream?

4) How is this any easier than the current system? Other than having a bit easier to understand interface, Ubuntu's Software Center doesn't provide any real benefit to end-users. Why not improve Synaptic instead of replacing it?

5) Eventually, this will be used to sell proprietary software. Along with the Free Software politics issues that I mention above, I take issue with offering software for sale in the same app as software that is free. I have no problem with commercial software in this context, but it should be made available in a seperate app, so it is very clear to the user what is free and what is not. We shouldn't be implimenting the iPhone store in GNU/Linux.

6) If this system is as centralized as the blueprint suggest, downstream distros will have to decide between offering all of the commercial software, etc that their upstream distro might be selling and not using AppStream at all. There needs to be a system in place to allow each distro to decide what to offer and what not to.

I do think a cross-distro standard for installing software is important. But not one that requires a 3rd party, internet-based service. While I agree PackageKit has its problems, what it offers is much more useful by itself than with any convoluted AppStore built on top of it.

[mendieta]

And it will enable app-centric distro-independet community of users, sharing meta-data like rating, screenshots, comments, etc.

Yes, this is a the goal for what I grasp. And it will reuse the existing (and very good, IMHO) tools to update/install/remove packages in Linux (way superior than the windows way).

We still need a universal, low level installer for proprietary software (prop games, etc). But such a tool would work in the back end, so I REALLY don't understand all the bitching, here.

[devius]

NO, it simply allows the same douche baggy development packaging to continue that cuased game ports to not come over to linux.

No, it just means that big game pubishers will have to come up with another excuse for not porting games to linux. Indie developers are somehow able to port games to linux just fine. I guess they must have way more money and resources than those big companies. It's the only explanation on how they can make both an .rpm AND a .deb package.

[meklu]

No, it just means that big game pubishers will have to come up with another excuse for not porting games to linux. Indie developers are somehow able to port games to linux just fine. I guess they must have way more money and resources than those big companies. It's the only explanation on how they can make both an .rpm AND a .deb package.

And not to forget, even an installer AND a tarball on top of all that. They sure have ridiculous amounts of resources, don't they?

[Thatguy]

Slightly OT, but this arrived in my in box this morning.

If Microsoft made toasters
----------------------------------------------
Every time you bought a loaf of bread, you would have to buy a toaster.
You wouldn't have to take the toaster, but you'd still have to pay for
it anyway. XP Toaster would weigh 15000 pounds (hence requiring a
reinforced steel countertop), draw enough electricity to power a small
city, take up 95% of the space in your kitchen, would claim to be the
first toaster that lets you control how light or dark you want your
toast to be, and would secretly interrogate your other appliances to
find out who made them. Everyone would hate Microsoft toasters, but
nonetheless would buy them
since most of the good bread only works with their toasters.

If Apple made toasters...
--------------------------
It would do everything the Microsoft toaster does, but 5 years earlier.

If Linux made toasters...
-------------------------
Anyone could build his own toaster from the spare parts in the garage,
but people would still pay money for pre-built toasters. All the parts
would be user serviceable, and the design plans would be freely
downloadable. Instead of the complexity of having to push a button, you
would simply type something like "toast-lightness?rk-bread-type=brown".
The toaster would burn your toast by default, but once you enable the
don't-burn-my-toast" feature in "toaster.conf" (as described in the
TOASTER-RTFM-HOWTO) it would toast reliably for years. People who eat
Linux toast say that it is better than Windows toast.


.... And Microsoft would tell everyone that Linux Toast causes cancer...

food for thought.

http://www.mail-archive.com/[email protected]/msg00254.html