[packaging] Meeting next week to discuss trusted third-party repositories

[Wichmann, Mats D]

Dan Kegel wrote:
> On Thu, Dec 4, 2008 at 8:13 AM, Tortanick <tortanick at googlemail.com>
> wrote:
>> Since you asked: my two cents:
>
> Thanks, I now link to your comment from the wiki page.
>
>> Upgrade Issues/Dependencies:
>> I think the best solution is to have dependences on various parts of
>> the LSB standard
>
> That's a requirement for LSB compliance already, no need to respecify
> it.
>
>> but prohibit dependencies on anything else, including other packages
>> from the same ISV.
>
> I think the LSB also specified that.

That's not really intended to go that far.

> However, I'm not sure it makes complete sense.
> It makes partial updates hard.  Consider an
> application structured as a small executable
> and a bunch of libraries, ISVs might well want to
> break it up into several packages to make updates
> less painful for their low bandwidth customers.

That's okay from the LSB viewpoint.

The underlying concept is that LSB promises certain things will
be available; to depend on more you need to make sure you've
solved the availability problem to your own satisfaction.
So if you want to break something into several packages such
as "core" plus "addons", or if you want to package out a
common piece that applies to several different packages, that's
okay as long as you've made sure that scheme doesn't make
things hard for people deploying.  Putting them all on a DVD,
or all in a repository, ought to make that okay, no?

Now the LSB spec may not use such fuzzy terms but that's
the intent.