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

[James Antill]

On Fri, 2008-12-19 at 07:20 -0800, Dan Kegel wrote:
> On Thu, Dec 18, 2008 at 11:54 PM, James Antill <james at fedoraproject.org> wrote:
> >  To be clearer, I'm realistic that if you encourage ISVs to each have
> > their own repo. ang give them full control of what ships when, then the
> > system will naturally bring about failures.
> 
> As long as the failure is confined to the ISV's own apps, we've won,
> as then they have incentive to fix their own problems.

 I don't think it would be, but even if it was I'd argue that it still
isn't a useful goal.

> b) for things like plugins, the app would install them into
> /opt/$vendor/lib/plugins/$targetapp and the package manager
> (and target app) would pick them up afterwards.  For instance,
> Adobe's firefox plugins might go into
> /opt/adobe/lib/plugins/firefox

 How is this better than just installing into / like a real package?
Apart from the fact someone has to write all the code to mirror things
correctly?

> The restrictions I'm proposing reduce the level of trust needed to
> *install* an app greatly.   The trust needed to *run* an app is
> a different matter, but as long as Unix system protections hold,
> all that's at risk is the user's own data and livelihood, not the

 Oh, is that all their risking :)

> The user has to trust the distro.  The distro can then whitelist
> a few ISVs (like Google and Adobe) because it trusts them,
> and because it can revoke that trust if the ISV abuses it.

 Except there is no good way to automatically revoke trust after it's
been added, in any package manager I know. But...

[...]
>   It kind of sounds like you're saying
> that there should be no ISV apps, and that all apps should come
> from the distro.

 No, maybe I've been writing too much detail, what I'm saying is that
all the major distributions have _small_ numbers of _large_ collections
of applications and there's a reason for that (if someone wants to
create a usable distro. with ZeroInstall/whatever that has a repo. for
each package ... feel free to prove me wrong).
 Ergo. if you want usable ISV packaging then IMNSHO you need to base off
something we know works. So create a small number of repos. which have
"all" the ISV applications in them (packaged by the ISVs), but managed
by people who care about the repo. as a whole (including their
"upstream") first.

 ----

 The same thing from another angle would be that if you look at:

https://www.redhat.com/apps/isv_catalog/browse_by_vendor.html

...you'll see that we're talking about a current _minimum_ of 2,194
different ISVs, your proposal means that we'll need an extra 2,194
different repos. to support all the ISVs (this assumes that you don't
want one repo. for picasa and one for google-desktop, which you've
already said isn't true).
 Now yum has some of the best tools for managing multiple repos. but
2,000+ repos is so far from expected behaviour it's just not going to
work well.
 But even if that works let's take, say:

https://www.redhat.com/apps/isv_catalog/AppProfile.html?application_id=1536

...which we want to use with oracle, any kind of special "trusted, but
without benefits" repos. aren't going to have any of the information
needed so you can do "yum install CGIScripter" and have it DTRT.
 So your proposal means that even if we do everything you want, what we
end up with isn't what the users would want ... and the amount of work
to get there would be significant (and has historically failed).

-- 
James Antill <james at fedoraproject.org>
Fedora