AppStream Ideas and Thoughts

[FlorianFesti]

On 02/15/2011 09:54 AM, James Rhodes wrote:
> I know why package managers work the way they do; having everything in
> a central repository at first seems to be a great way to ensure that
> every software that the distribution wants to offer has the
> dependencies available for it, which for well-known open source
> software is fine.  There's a high change that users will be able to
> find the software they want in the repository.
As you kinda admit getting the dependencies right is not trivial (There 
are in fact some nicely NP-complete problems lurking there). A package 
format alone does neither solve this nor does it integrate with the 
distribution in more than adding the duplicates into their database. May 
be some of this difficulties can me solved by leveraging the work 
already done in the distributions but it still is not trivial.

There are a couple of other reasons for why distributions look like the 
way they do, that need to be taking into account (list does not claim 
completeness):

Have someone taking care of every component that got packaged. How can a 
user expect that the vendor is capable of taking care of all issues that 
may emerge in the libraries they have bundled. The distributions are 
assigning some one to every library and they have a separate security 
response team to make sure the maintainers do their job.

Is such a packaged world the amount of data need for updating a 
(compromised) library is enormous. This basically shuts down updates for 
everything but the most urgent exploits and even they generate an ugly 
amount fallout - especially as these updates come in one big chunk 
(think about an exploit in zlib).

The distributions are a trusted third party that makes sure that the 
software they get from upstream is not malicious. Sure vendors with a 
strong brand don't need a third party (e.g. the adobe repositories). But 
the target audience of such package formats typically don't have such a 
brand.

The knowhow of good packaging and package maintenance does not scale 
down very well. There is a serious amount of general knowledge and 
continuous work needed. This is significantly easier within a big 
projects dedicated to this task than on your own. No matter how good 
your tools are they are still putting an pretty big burden onto the 
third party vendors (have a look at the rpms they build).


I think the overall approach is flawed. If I were interested in this 
topic I'd use the SUSE build system tools or something similar and offer 
a service to create packages for all distros. May be charge a fee for 
closed source applications or offer a build system as an appliance or 
cloud image. Then setup an repository or a repository list that makes it 
easy for users to subscribe.

Florian