Ticket #164 (closed defect: fixed)
installer should know about apt-release clusterinfo
| Reported by: | broder | Owned by: | amb |
|---|---|---|---|
| Priority: | normal | Milestone: | The Distant Future |
| Component: | -- | Keywords: | |
| Cc: | Fixed in version: | ||
| Upstream bug: |
Description
Soon, hopefully, machines in various Moira clusters around campus will have "production", "proposed", and/or "development" values for the "apt-release" key in clusterinfo.
The Debathena installer script should somehow know about this field, and should use it to frob /etc/apt/sources.list.d/debathena.list appropriately at install time.
This allows us to test how a system handles being installed with the packages in -proposed (or -development).
This one is a little trickier than #163 because we don't have debathena-clusterinfo or debathena-getcluster installed when /etc/apt/sources.list.d/debathena.list is written.
It may be that we want to install debathena-getcluster, find out the clusterinfo, and then re-generate /etc/apt/sources.list.d/debathena.list, but even this seems slightly non-ideal, as for a small period packages will only be pulled from production.
Change History
comment:3 follow-up: ↓ 4 Changed 14 years ago by amb
- Owner set to amb
- Status changed from new to assigned
There's a fix for this checked in which needs a bit of rework; see r24765 and subsequent debate.
comment:4 in reply to: ↑ 3 Changed 14 years ago by amb
- Status changed from assigned to committed
The requested reworking was done a while ago; this is checked in and tested and awaits deployment.
comment:5 Changed 14 years ago by amb
- Status changed from committed to assigned
This support doesn't actually work because hesiod contains both apt_release entries on development machines. Unclear if we want hesiod cluster info to have both apt_releases, but the installer should probably cope with it anyway if it does. (This should still be fine on proposed machines, though.)
comment:6 Changed 13 years ago by amb
- Status changed from assigned to proposed
Multi-clusterinfo machines fixed in r25222.
comment:7 Changed 13 years ago by jdreed
This was deployed, but see the thread on source-commits about whether we want to go back to "development implies proposed" or what? Arguably, it's Wrong(tm) to have two unversioned cluster tags of the same name (because the second one always wins in getcluster)
Is there a use case for this other than "This allows us to test how a system handles being installed with the packages in -proposed (or -development)."? auto-update should bring in packages from the other releases soon enough...
It might be more helpful, especially for virtual machines, if the installer could let you manually specify which release you want to install.