Ticket #1321 (new task)
Kill old-gdm with fire
| Reported by: | jdreed | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | Current Semester |
| Component: | -- | Keywords: | |
| Cc: | Fixed in version: | ||
| Upstream bug: |
Description
The only release on which we even pretend to support old-gdm is Squeeze, which has both a convention GDM 2.20 (packaged as gdm) and modern GDM 3.0 (packaged as gdm3). Wheezy does not have a gdm package. Ubuntu has a gdm package which is secretly GDM 3.x.
The rules file for gdm-config is terrible, and we should put effort into pretending to support GDM3 anyway.
We should drop support for old-gdm. This will force Squeeze users to GDM 3, or require them to use manual-gdm-config. If this is objectionable, we could wait until Wheezy release + 365 days, at which point upstream will kill Squeeze.
See also #1059.
Change History
comment:2 in reply to: ↑ 1 Changed 11 years ago by kaduk
Replying to jdreed:
Thinking about this more, we don't have to wait until Squeeze dies. Wheezy has now been released, Squeeze can get relegated to "maintenance mode", so we can fix the gdm-config bugs (currently in our workflow), release the package, and then drop all the GDM2 code and throw nobuild files in for Squeeze. Squeeze users using gdm2 can continue to do so, but will get no Debathena updates. In the unlikely event that our gdm-config introduces a CVE or something, we can do a one-off build based on our last source package for Squeeze (which will be in our repo).
That sounds okay. I don't think the potential squeeze gdm2 userbase will be up in arms; they want a basically unchanging system anyway.
I vaguely wonder if we want to take this opportunity to split the package into gdm-config and gdm3-config, but I suspect that will cause more problems than it will solve.
Your assessment seems correct.
Thinking about this more, we don't have to wait until Squeeze dies. Wheezy has now been released, Squeeze can get relegated to "maintenance mode", so we can fix the gdm-config bugs (currently in our workflow), release the package, and then drop all the GDM2 code and throw nobuild files in for Squeeze. Squeeze users using gdm2 can continue to do so, but will get no Debathena updates. In the unlikely event that our gdm-config introduces a CVE or something, we can do a one-off build based on our last source package for Squeeze (which will be in our repo).
I vaguely wonder if we want to take this opportunity to split the package into gdm-config and gdm3-config, but I suspect that will cause more problems than it will solve.