AppStream Ideas and Thoughts

[James Rhodes]

On Wed, Feb 16, 2011 at 2:37 AM, FlorianFesti <ffesti at redhat.com> wrote:
> On 02/15/2011 11:32 AM, James Rhodes wrote:
>>
>> You see, I would think that the distribution owners would actually
>> want to hand that work off to the person building or developing the
>> software in the first place, since the developer knows when they
>> release updates, they know what dependencies their software has and
>> hence they can maintain their packages in a much more timely and
>> secure manner than having a third-party distributor build and ship
>> them.
>
> You think wrong. We would even like hardware vendor leave the development of
> drivers to the community (and provide the specs).

I fail to see how the hardware analogy is appropriate in this case.
We're talking about original open source software in this particular
case.  Moving the packaging requirement off the distributor and onto
the developer is a win-win situation.  You have less work to do, and
the developer gets to distribute his software to everyone, not just
the distributions that decide to support it.

>>
>> On Tue, Feb 15, 2011 at 9:11 PM, FlorianFesti<ffesti at redhat.com>  wrote:
>>>
>>> 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).
>>
>> I understand your point here to be that the original software
>> developer may not have the bandwidth available to ship updates to all
>> the users of their library / application, right?  In that case, the
>> distributor could mirror the the AppTools package on their AppServer,
>> and the updating system would use that (it obviously prefers using the
>> distributor's service over an individual's server; and since it's a
>> mirror, there's no need for each package to be managed by the
>> distributor, it can be an automatic mirroring).
>
> This issue goes beyond mirror bandwidth. Think about having 100 application
> packages each containing 20 libs and 200MB. Now consider that every lib has
> an critical bug every two years on average.

I'm sorry, I just don't see what you're saying here.  In the case that
the distributor mirrors the package from the original developer, it's
exactly the same in terms of getting the package to end users,
bandwidth or otherwise, as the current system that's employed now.

>>> 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.
>>
>> In order to ensure that updates you receive come from source that
>> originally produced the initial package you installed, you use
>> signing.  It's really that simple.
>
> This is not what I am talking about. Read the paragraph above once again.
> With a signature you can verify the source but you don't know whether you
> can trust the source or not. This is not an issue for well known sources but
> there will be lot's of others.

You trust a source when you first install software from them, just
like you trust a source when you first add a repository.  You then use
signing to confirm that the package is really coming from who it says
it is (and that you trust that person).

>>>
>>> The know how 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 really don't understand what you're trying to say here.
>
> I say most upstream and especially commercial software vendors do a pretty
> bad job with packaging right now and I don't see why one should expect them
> to become better.

Because now they have a package format in which they can distribute
their software to every Linux distribution at once, and still have all
the features of package management such as resolving dependencies.
They don't have to rely on the ugly binary installers to get the job
done.

Regards, James.