Alternatives for application-specific package management

On 11/27/05, Reinhard Tartler <siretart at gmail.com> wrote:
>
> > I think that what Carlos wanted to point out is that certain
> > categories of packages need extra, domain-specific work that's not
> > easily included in the general package management tools.
>
> If the software is extensible with extra data, the user should install
> it in his home. I don't see what apt or other package managment tools
> can do about that.


I disagree. In a way, apt already does something -- packages such as
freepats and msttcorefonts are just the kind of "application specific"
packages that I mentioned in my original post. But they are just "raw"
packages that are needlessly hard for the novice to find. What is lacking,
in my opinion, is a simple standard to allow specific applications (such as
the "System > Settings > Fonts" application) to read the package database in
a more inteligent way, selecting only the packages that apply for each
application: font management, sound font management, and so on.

Please note that I do not propose any change to the existing package
management tools; what I propose is to discuss a framework to provide some
package management functionality on some of the system settings tools, in a
simple and standard way. There is no need for big architectural changes,
although packagers would need to follow a few rules just to make sure that
the packages would be correctly processed by their specific managers,

> His example with MIDI instruments means that there are (in theory) an
> > unlimited number of instrument packages, but there are only a limited
> > number of instruments that can be installed/configured at the same
> > time.  This requires extra constraints & configuration that's not
> > possible with general purpose apt frontends.
> >
> > In the case of TrueType fonts, you don't always want all fonts to be
> > installed at the same time (cluttering the font list in *all*
> > applications), but you want to have them around in case you need them.
>
> I don't quite understand. If a user wants extra fonts the system
> administrator does not provide for him, he should drop his fonts in
> ~/.fonts. Same for his MIDI instruments.


Sincerely, and without irony: my proposal was based on the assumption that
ease of use is one of Ubuntu's main goals. Most users never heard about
~/.fonts. Even less users know how to find new fonts to install, or how to
preview them. Having a good font management applet would be a worthy goal --
perhaps not for Dapper, but even so, a worthy goal.

I also think it would be up to his application using the MIDI
> instruments to provide some interface for easy installing of new
> instruments, if something like that is desired.
>

Again, I disagree. Choice *is* good, and it's fine for the user to be able
to choose between a number of music synthetisers, but we stand to gain
nothing if every sequencer or softsynth has to provide its own instrument
management subsystem. These pieces should be provided and managed in a
standard way, allowing all related software to take advantage of them.

--
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/7b959f80/attachment.htm