Infrastructure for meta-distribution projects

Jeremy Malcolm Jeremy@Malcolm.id.au
05 Jun 2003 09:04:23 +0800


--=-PutjPjo9s1uYVJ+spQ0e
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2003-06-04 at 21:00, Ben Armstrong wrote:

> Well, tags are handy for packages obviously belonging to "legal".  But wh=
at
> about packages that are not specifically legal-oriented but which -Lex fe=
els
> 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 tryin=
g
> 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.

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



--=-PutjPjo9s1uYVJ+spQ0e
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iQB1AwUAPt6XFr/mBljD2JABAQLcCwL/V/9cEnWMDfzFzz3HPHNghhRQa0+5NL8z
avtY6TIe7bSDf0Mt2xGD8bQi2KvGXcSSee/CgQtDea39kCfFTSWTJJwLCysi0c4H
MFVlLn5qUtowCgvzXwGbHBjHwFm+6fEf
=XYoc
-----END PGP MESSAGE-----

--=-PutjPjo9s1uYVJ+spQ0e--