On Wed, 2003-06-04 at 21:00, Ben Armstrong wrote: > Well, tags are handy for packages obviously belonging to "legal". But what > about packages that are not specifically legal-oriented but which -Lex feels > belong in a base -Lex system? Is it appropriate to also tag these "legal"? Yes. You can have as many tags as you like, but not only that, you can (in, say, debian-lex-common) distribute a patch to the tag database that adds your "legal" tag to whatever other packages you see fit. People who don't have "debian-lex-common" installed won't even *see* your tags. > Meta packages provide precise and centralized selection of a set of > "recommended" packages. I see tags as being more useful for people trying > to locate other material not necessarily selected to be part of the > subproject, but which still may be within the same scope of interest for the > subproject user. You could have a package tagged "legal" that is not yet as > stable/full-featured as an alternative, and is therefore not recommended by > -Lex. I don't disagree with that, but I don't see the single "Debian-Lex" task approach being fine-grained enough. To simplify, we will have a Debian-Lex server and a Debian-Lex workstation. The packages they want to install will be quite different. We can have "server" and "workstation" metapackages, but which of those, if either, should be part of the task? Do we split it into two tasks? What if there are ten distinct uses for Debian-Lex? Using tasks then becomes fairly pointless, and we should tell people just to use aptitude to search for the individual meta-packages, which is user-unfriendly. Package tags don't suffer from this issue because you can in the first instance filter for the "legal" tag and drill down to sub-tags (workstation, server) from there. The only packages that you would then need to include in the task would be debian-lex-common and a tags browser (so, it doesn't matter that tags aren't integrated into the installer yet). > I think the meta package approach will continue to be a reasonable way > to install a default set of packages, whereas tags give the user the > ability to fine-tune package choices without having to slog through > several thousand packages to find appropriate ones. I will consider writing a patch to med-common-devel that will generate metapackages and tags from a common source. In the long run though, I think tags are more flexible (I only want to install packages that satisfy "legal-system::common-law" and "legal-subjects::taxation-law"), so the metapackages method of installation would be deprecated. Anyway, that's the way I think I want to go with Lex. -- JEREMY MALCOLM <Jeremy@Malcolm.id.au> Personal: http://www.malcolm.id.au Providing online networks of Australian lawyers (http://www.ilaw.com.au) and Linux experts (http://www.linuxconsultants.com.au) for instant help! Disclaimer: http://www.terminus.net.au/disclaimer.html. GPG key: finger.
Description: This is a digitally signed message part