Comments within -------- Original Message -------- Subject: Re: [Desktop_architects] What's an ISV to do when a distro upgrade disables the ISV's repo? From: Dan Kegel <[email protected]> To: Matthew Tippett <[email protected]> Cc: [email protected] Date: 09-05-05 04:11 PM
> On Tue, May 5, 2009 at 12:50 PM, Matthew Tippett <[email protected]> wrote: >> Why does the the distro disable 3rd party repositories... Some answers >> could include >> >> 1) Effectively increase the absolute priority of the distribution >> packages to allow the update. If the third party app is force to be >> removed to satisfy a dependency, so be it. >> 2) Remove the possible sources of conflicting/unstable/incorrect 3rd >> party libraries that may have a higher version match than the distributions. >> >> (Any other thoughts?) > > Those are all fine reasons. In the past, third party repositories > have been a source of instability, so disabling them was a good > idea. The idea of "5 Why" is that you are supposed to determine which of the options has the most plausible basis and re-examine the "why" for that. (Wash/rinse/repeat around 5 times down a few paths). We can go a bit deeper if the discussion warrants. > > Now that large ISVs are considering using the package manager to > update their apps (after all, why reinvent the wheel?), it might make > sense to reexamine that practice. If, say, Ubuntu decides to have > a whitelist of trusted ISV repositories (with preloaded public keys), > perhaps those whitelisted repos should not be disabled on upgrade. > (After all, if they were doing anything risky, they would't be in the > whitelist, at least not for long.) In my mind, the fundamental issue is ownership of the files and packaging system on the disk. Realistically most users don't incur a cost for support of a Linux distribution which allows an aspect of shared risk for software sources. For environments that do have a measurable cost of software misconfiguration the use of third party repos is most likely considered bad (this is either paid support like RH, or an SOE in a large organization). Deeper investigation into the root causes (like above) should allow a common ground to be established to understand where the risks and trust issues really lie. I doubt that Canonical would be willing to trust 100's of partners, in the same way that a large ISV would be willing to engage with 10's of leading distributions to fit into their trust models. ... > Yes, b) would be the method of choice unless it resulted in > too many users apathetically hitting cancel and saying > "Why are you bothering me with questions?", and thereby > becoming vulnerable to attack because they are running an > out of date app. Remember, every extra > keystroke or mouse click the user has to do significantly > reduces the number of users who make it through any particular > task; making the action take more than one click might mean having > lots of insecure users. > To reduce this problem, you could imagine doing an in-app notification, > then having a tiny and heavily audited suid app that can do absolutely > nothing except re-enable the isv's repo. > This would make the interaction flow better in the app, and would > reduce the number of keystrodkes needed. > Any setuid app makes me nervous, but the risk of having > a tiny setuid helper app might well be lower than the risk of > having lots of users with out of date apps. I agree, so we need to look at the emergent behaviours is other large ISVs on other platforms. Most (adobe, apple, sun, etc) seem to opt for a model that the app does the download and then cooperates with the packaging system to ensure an install. Very rarely do they attempt to get the OS to manage the updates for them. This would result in the same end-point that you are suggesting, effectively a portland style xdg-install-package, a small setuid application. If you do want the OS to do the updates, you will always be left with trust/support/cost issues. The alternative here is to look for the distributions to do more than whitelist, and proactively provide a 3rd party distribution mechanism as a first party. Microsoft does this on occasions for replacement ITB drivers that are causing support issues. The Ximian Red Carpet model is probably the best example of this. > > A real life user installed Ubuntu 8.10, installed Chromium for Linux on it, > then upgraded to Ubuntu 9.04, and asked why Chromium wasn't updating > any more. I kind of meant abstracting the users experience into a documented use case that would be usable as a model for working through the problem. Something akin to http://en.wikipedia.org/wiki/Use_case#Use_case_templates. They are painful, but they provide a great basis for understanding what the user is doing expecting and experiencing. (I would be more than happy to work with others in defining use cases for some of the issues this list deals with). Regards, Matthew _______________________________________________ Desktop_architects mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/desktop_architects
