Ticket #213 (closed task: fixed)
Craft a policy on the implications of each metapackage and what software goes where
| Reported by: | jdreed | Owned by: | jdreed |
|---|---|---|---|
| Priority: | normal | Milestone: | Summer 2010 (Lucid Deploy) |
| Component: | -- | Keywords: | |
| Cc: | Fixed in version: | ||
| Upstream bug: |
Description
We started to do this over e-mail (Subject: the impact of each metapackage), but we should, by the summer, come up with a policy regarding how software gets added to -extra-software, -third-party, or one of the major metapackages (clients, standard, login, etc).
Change History
comment:1 Changed 15 years ago by jdreed
- Owner set to jdreed
- Status changed from new to assigned
- Milestone set to IAP 2010
comment:2 Changed 15 years ago by jdreed
Draft policy at /mit/jdreed/debathena/doc/metapackage-policy.txt.
It's under RCS (yes, RCS). debathena-dev has write bits.
comment:3 Changed 15 years ago by geofft
I updated that doc a bit, mostly to address and remove the TODOs and to require classes of packages rather than specific software by name. The rest of it looks good to me, and we should get another okay or two and declare it policy.
Note that this doesn't actually address the impact of top-level metapackages (-standard vs. -login vs. -login-graphical vs. -workstation), nor a possible restructuring of -extra-software into something else that doesn't cause people to hold grudges against me after I tell them to say "yes" to the installer prompt. Do we want to do that?
