Jono Bacon <[EMAIL PROTECTED]> writes: > I just wanted to get your views on something. I think it could be useful > to have pre-configurations for different uses. ... > > So, imagine I install "kubuntu-kde-devel", it would pull in > build-essential, kdevelop, qt-dev, unit testing software, kdbg and > various other tools to allow KDE development, but also configure Firefox > so there is a toolbar bookmark to the Qt online docs as an example. > Imagine a use case was "embedded development" - the package could > install and configure cross-compilation tools, which are traditionally a > real pain to set up.
I think this brings up the old discussion of 'meta-packages' in general. meta-packages are empty packages, which are only used to conveniently convince apt to install a set of packages. This can be seen commonly in packages like 'ubuntu-desktop' and friends and works generally quite well. Now imagine a meta-package 'kubuntu-kde-devel'. If a user removes one package the meta-package depends on, which might be on purpose, or by installing another package which conflicts against one package of "kubuntu-kde-devel's" dependents, apt decides that the meta-package needs to be removed as well, because its dependencies cannot be fulfilled anymore. This is correct, but surprises users, because they don't want to 'loose' the 'kubuntu-kde-devel' functionality. An improvement to this would be to use tasksel. Tasks are written in the package indices on the archive AFAIUI. tools like tasksel or aptitude can be told to install all packages in a given task. Later, if the user decides to remove a package, no surprise come anymore. The problem here is that it is quite hard to install custom tasks. Users generally don't setup their own archive software to fiddle with the set of tasks in the package indices. A more sane approach IMO would be to use Debtags. There you could invent for your specific domain your own vocabulary of tags, and mark packages appropriately. You don't need meta-packages or tasks here, you need to define the set of tags (or the single tag) a package must have in order to be installed. The advantage here is that you can easily install your own tag sources. We could provide 'official' debtags sources in the archive, and let users provide their own tags for existing packages. There are a number of frontends for editing tags on packages. The most convenient is perhaps GoTagging, which is a Webbased frontend. Enrico Zini has others as well! > If this is doable, it could open up Ubuntu and Kubuntu to really > interesting use cases, which are a pinch to set up. Then imagine we > allow the community to create these meta-packages (with a process to > ensure quality), we could have a little GUI application which could > browse a bunch of these use cases and install the relevant package for > that use case. I don't feel very comfortable with this idea. This effectively means that we encourage people to run their 3rd party repositories, which means that users would have to carefully check the repositories contents (there might be other packages than 'just' the meta-packages) and the gpg id, a task too complicated for the average user. I feel that debtags is far superior here than continuing to advocate even more meta-packages. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- Ubuntu-motu mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
