Alternatives for application-specific package management

On 11/25/05, Matt Zimmerman <mdz at ubuntu.com> wrote:
>
> 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>
>
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.


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.

This solves the problem in a general way, whereas your approach requires a
> significant amount of work for each new category.
>

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: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: carribeiro at gmail.com
mail: carribeiro at yahoo.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ubuntu.com/archives/ubuntu-devel/attachments/20051127/af396d32/attachment-0001.htm