On 11/25/05, Matt Zimmerman <<a href="mailto:mdz@ubuntu.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">mdz@ubuntu.com</a>> wrote:<div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> On Sun, Nov 20, 2005 at 08:03:24PM -0200, Carlos Ribeiro wrote: > For the lack of better name, I am calling it the "Application Specific > Package Management" problem. <snip> </blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The most promising approach I've seen is debtags, which allows packages to be categorized in meaningful ways by attaching an arbitrary number of tags to them.  There was a debtags-enabled Synaptic at some point in the past, but I'm not sure where it stands today.  Michael Vogt would presumably know.</blockquote><div> Thanks for you answer. You're right on several counts: this is not a new problem, and it's not a infrastructure problem. However, there's clearly room for improvement in the way the "application specific packages" are managed. I think my original post was not as clear as I wished, so please take my apologies for that. Let's restate the proposal in a more straighforward way: 1) Provide support for basic package management functionality in applets such as the "System > Preferences > Fonts". I believe that this kind of functionality is missed by many users, and would make Ubuntu easier to use, specially for people migrating from other OSs. Please note that this is a long term goal; I do not expected that all applications will be rewritten or extended in the short term. I think about it more like a "roadmap" thing. 2) Define very simple rules for "application specific" packages: a) define a generic mechanism to select the correct packages from the package database; b) define rules about how the packages should be structured. Item (a) is a decision about how to tag the packages. There are a number of possibilities, such a tag in the package name ('-ttf', or '-soundfont'); use of the "provides" tag; or debtags. As long as there's a way to select the packages from the database, it's ok. Item (b) is concerned with two problems; the system must be kept simple, and it should be backwards compatible. Simplicity is attainable by defining that the add-on packages should contain only the minimum of stuff needed (for example, just the font files and a few preview samples). Backwards compatibility means that the package should install just fine from apt-get or synaptic. The only thing that would be gained through the application specific management interface would be the ease to select the packages from a shorter and less confusing listing (something that's hard to do today, given the size of the package list), and (hopefully) the ability to preview the contents of the package in a context that makes sense. Example: ** A TrueType font package contains fonts that go into /usr/share/fonts. The preview could be handled either by allowing fonts to be extracted from the package just for preview, or by including some images for previewing. ** A Soundfont package contains files that go into /usr/share/midi/soundfont. The preview can also be handled either by allowing individual fonts to be extracted for preview, or by including audio snippets (standard WAV files) for listening. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">This solves the problem in a general way, whereas your approach requires a significant amount of work for each new category. </blockquote></div> You're right, that's why I think about it more in a 'roadmap' way. It's a lot of work, and it's pretty easy to overdo it. So yes, I am aware of the problem and willing to work to avoid it. -- Carlos Ribeiro Consultoria em Projetos blog: <a href="http://rascunhosrotos.blogspot.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://rascunhosrotos.blogspot.com </a> blog: <a href="http://pythonnotes.blogspot.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://pythonnotes.blogspot.com</a> mail: <a href="mailto:carribeiro@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> carribeiro@gmail.com</a> mail: <a href="mailto:carribeiro@yahoo.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">carribeiro@yahoo.com </a>