Alternatives for application-specific package management

On 11/26/05, JanC <janc13 at gmail.com> wrote:
> > > For the lack of better name, I am calling it the "Application Specific
> > > Package Management" problem.
> >
> > This isn't really an underlying problem in package management.  It's the same
> > package categorization problem that various people have struggled with over
> > the years, and it can be solved with extensions to the package management
> > system which don't involve any infrastructure changes.  Indeed, this is
> > purely an issue for package management frontends, such as Synaptic.
>
> 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.

> 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.

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.




--
regards,
    Reinhard