Mark,<div><br></div><div>Thanks very much for your reply!</div><div><br></div><div>I am approaching this issue from the standpoint of desktop computing; I have a hunch if that were solved, enterprise solutions with regards to cached centralized repositories wouldn&#39;t be difficult to implement at all. I would even go as far as to say that we have <i>already</i> solved this with centralized package repositories! Of course that is pure conjecture on my part!</div>

<div><br></div><div>In regards to your comment about a credible attempt at standardizing package management across Linux: what do you consider credible? Are there technical requirements or community politics that in your eyes need to be followed? I have been trying to familiarize myself with the approach the LSB took, and I can see why it has been so contentious.</div>

<div><br></div><div>I began this line of thought with Gandhi&#39;s famous quote in mind, &quot;Be the change you wish to see in the world&quot; and asking myself what the greatest good I could do for Linux is. I think I would like to start working on my idea of the &quot;solution&quot; to the Linux packaging issue, but I don&#39;t want to do so naive of the technical and political barriers. I am curious, has anyone working on Ubuntu ever designed their ideal decentralized package management system?</div>
<div><br></div><div>I have also been doing research on the various options that exist that people have already developed (for instance zero-install); all of them have what I consider to be a flaw: they introduce yet another package format. It seems to me that if anything were to ever become successful, it would have to bring together all package formats instead of splintering them further.</div>
<div><br></div><div>The rough draft of my use-case goes something like this:</div><div><ol><li>A user downloads this decentralized package management tool (let&#39;s name it &quot;Foo&quot;) using their distro&#39;s centralized repository. Maybe Foo even comes pre-installed and the distro uses Foo for their software installation.</li>
<li>A user goes to a website and downloads a compiled, packaged piece of software in whatever package format they like.</li><li>The user double-clicks the package and Foo is launched.</li><li>Foo resolves dependancies and installs the software.</li>
</ol></div><div>I am intentionally being vague with step 4. Rather than biasing everyone with my ideas, I&#39;d like to first see if people even think this usage case is a <i>good</i> idea and if so, see if anyone had ideas on how to implement it? What does the everyone think?</div>
<div><br></div><div>Thanks,</div><div>Kate<br><br><div class="gmail_quote">On Tue, Mar 9, 2010 at 5:58 AM, Mark Shuttleworth <span dir="ltr">&lt;<a href="mailto:mark@ubuntu.com" target="_blank">mark@ubuntu.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Kate<br>
<br>
It&#39;s an interesting and thorny problem. I don&#39;t think Ubuntu has all the<br>
answers but we can perhaps share some insight.<br>
<br>
There are great advantages to packaged software. If you talk to folks<br>
who manage large numbers of systems, they will share a preference for<br>
getting as much as possible from a central package repository. That&#39;s<br>
why there&#39;s continual pressure to add more packages to the archives of<br>
Debian, Ubuntu and all the other distributions.<br>
<br>
On the other hand, the packaging process introduces delays, friction,<br>
and editorial freedom that isn&#39;t always welcome.<br>
<br>
We would certainly be a supporter of a credible attempt to simplify and<br>
standardise packaging across Linux. Unfortunately, the LSB and other<br>
efforts have usually fallen into the approach of picking one, and trying<br>
to get everyone else to adopt it. Fans of Debian and Ubuntu would say<br>
that the .deb format offers a better long term experience to users than<br>
RPM can, and I&#39;d agree.<br>
<font color="#888888"><br>
Mark<br>
</font></blockquote></div><br></div>