On Mon Jul 02, 2007 at 01:18:57PM +0200, Reinhard Tartler wrote: > 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.
For meta-packages in the metapackages section, apt installs Recommends: as well. This allows you to define essential (Depends: ) and non-essential (Recommends: ) packages in the meta-packages. The non-essential packages can be removed. The ubuntu-desktop package has been doing this, things like firefox and OO.o are in Recommends. I think this makes meta-packages quite attractive. > 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. It's pretty easy to make tasksel .desc files. You could ship a set of tasks and install them to /usr/share/tasksel/ and tasksel/synaptic will pick them up. No need to mess around with archives. > 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. I haven't really had a chance to look into debtags much. To me it seems intriguing, but not really very practical yet. Perhaps I'm not quit getting it but I see lots of query and tag manipulation tools, but in the end, how are users going to install packages? It sounds like work is being done to integrate it with apt but it doesn't seem like it's there yet, from what I read. Adept is the only package manager I could find that has support for debtags. It does seem pretty cool though. > 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! This seems to be http://debtags.alioth.debian.org/ btw ( I had to google for it). > > 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. Although I agree that making it super easy to create metapackages is a tad scary, people already create 3rd party repos and people on the forums are advocating equivs to create their own metapackages. Maybe having an easy, and maybe more importantly controlled, tool to do this would help the situation, maybe. > I feel that debtags is far superior here than continuing to advocate > even more meta-packages. We only have 8 meta-packages in the metapackages section of the repos. I don't really see there really being a big issue with putting more in there. I could be entirely wrong, I hear ocassionally about a general dislike of meta-packages, but I'm not sure if that's because they are used so much for transitions and for normal packages. Perhaps some of the more experienced devs could help me out with that :-) Overall, IMO, it could really work to start out with some meta-packages for common tasks or package groups because meta-packages are easy to create and easy to use for the end-user. Then when debtags gets farther along we can migrate to that. Any more thoughts? I'm pretty curious as to what "tasks" people think would be useful. We've seen development tasks so far. -Jordan -- Ubuntu-motu mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
