Custom Query (1145 matches)

Reported by geofft, 13 years ago.

Ubuntu put what we call "new GDM" in the gdm package, starting from version 2.25. Debian, deciding that it was eventually going to be part of GNOME 3, put it in the gdm3 package and kept a gdm package around with "old GDM". We only ever tested this on Ubuntu. This causes the following immediate problem on Debian:

geofft@leveret:~$ aptitude -s install debathena-login-graphical
[...]                                                          
The following packages have unmet dependencies:                
  gdm3: Conflicts: gdm but 2.20.11-4 is to be installed.       
The following actions will resolve these dependencies:         
                                                               
     Remove the following packages:                            
1)     gdm3                                                    
2)     gnome                                                   
3)     gnome-desktop-environment                               

The less immediate problem is that our build infrastructure conditionalizes on gdm package version, but on Debian, both gdm and gdm3 exist. One answer (probably the easier one) is to substvar in our gdm dependency, and on Debian where gdm3 exists, set NEW_GDM and set the substvar to gdm3, and simply not support old-gdm on Debian releases that include new-gdm. (This is analogous to what we are forced to do on Ubuntu.) If someone wants to be particularly ambitious, they could try making multiple binary packages debathena-gdm-config and debathena-gdm3-condig.

Reported by jdreed, 12 years ago.

We spend way too much time and effort on updating thirdparty, and have to play stupid games to work around broken dependency resolvers, and the whole thing is just too fragile. I propose a new design for thirdparty that makes everyone's lives easier (where "everyone" is me and alexp), and fixes #372:

Basically, we supply a list of packages (possibly separated into dependencies and recommendations), but I think we can do away with those concepts. This list can be a global list, or it can be per-distro. debathena-thirdparty is a package that knows where to find these lists, copies them locally, and iterates over the packages, apt-get installing each one (presumably not in its postinst, but rather as a cron job, or a trigger at the end of auto-update, or something). If a package fails, it retries. After 3 consecutive failures, it whines, either via athinfo (which we can add a new Nagios check for, or use update-status, or something) or syslog, or whatever. When someone uninstalls thirdparty, we can either remove those packages (again, failing if there are dependency issues), or perhaps mark them as auto-installed or something?

Benefits:

• Changing the membership of thirdparty is as simple as editing a plain text file, no rebuilds are necessary.
• We don't have to play stupid dependency games
• Removal of metapackages is far less likely.
• Fixes #372
• Installs possibly go faster as we can relegate this to firstboot or something?

Cons:

• We're reverting to what are essentially control files. (Counterpoint: They worked.)
• There's no longer a hard guarantee that all of thirdparty must be installed for a machine to call itself cluster.

I'm fully aware that using APT is the Right(tm) way to do this. But it causes more trouble than it's worth, IMHO.

Reported by tabbott, 16 years ago.

We should make our msmtp package that fixes the Resent-To bug available in Debathena.