Re: [Cooker] [Bug 1692] [gcc-colorgcc] update conflicts preventing install of latest colorgcc

[Gwenole Beauchesne]

Hi,

The original reporter would like colorgcc to support both 2.96 and 3.2.2. The current approach is not good because:

1) Installation of both gcc2.96-colorgcc and gcc-colorgcc packages would require versioned config files. This is insane due to the duplicates problem I talked about earlier. Config files would differ only by gcc paths, a priori, i.e. from stock *-colorgcc packages installation. Modifying colors et al. in one would force the user to make similar changes in any other instance of colorgcc config file.

2) Colorgcc alternative weight is 20 for 3.2.2 and 15 for 2.96. Plain compiler alternatives are 10 and 5, respectively. Here, assuming we had a solution to install both *-colorgcc packages, another problem would occur if we were to remove gcc-colorgcc. Indeed, the new gcc symlink will be to colorgcc-2.96 which is bad because the system compiler is 3.2.2 and that should be preferred, always.

3) A solution to (2) would be to set colorgcc-2.96 alternative weight to 10. Now imagine the user sets gcc2.96 as the primary compiler, thus wants colorgcc-2.96, consequences are:
(a) he will have to update-alternatives --config explicitly against colorgcc-2.96
(b) alternatives update state will switch to manual
(c) From (b) and (c) and if he removes gcc2.96-colorgcc, he will have to:
- switch back to automatic mode, but he will will get 3.2.2 as the default compiler but used/wanted 2.96
- explicitly set plain gcc2.96 in manual, once more.

4) Concerning updates from 9.0 to 9.1. Suppose gcc2.96-colorgcc was installed. We need a way to migrate that state to 9.1 land which as you suggest and I am doing doesn't provide gcc2.96-colorgcc any longer.

4.a) Obsoletes/Provides: gcc2.96-colorgcc from gcc-colorgcc is not perfect.
(i) say he was in auto mode and installed only gcc2.96-colorgcc thus having 2.96 as primary compiler. The new colorgcc-3.2.2 is used instead of the expected 2.96 one.
(ii) say he was in manual mode (--config explicit for colorgcc-2.96), link is likely to become dangling.

4.b) We don't obsolete gcc2.96-colorgcc, that package remains and colorgcc-2.96 still exists. This is good for the user but that package is naturally obsolete.

5) We can involve some trickery and add another level of link. e.g. gcc -> gcc.real -> gcc-<version>. When a *-colorgcc package is installed, we get gcc -> colorgcc -> gcc.real -> gcc-<version>.

5.a) This could work nicely but we are populating bindir with garbage. I find uneasthetic *.real names.
5.b) gcc.real would be the update-alternatives name. gcc being a symlink to gcc.real. We are lucky symlinks to the same target doesn't seem to conflict among different packages %filelist.
5.c) This duplicates internals of update-alternatives system. That's true we already have in real world, gcc -> /etc/alternatives/gcc -> gcc-<current>. One would think it'd be interesting to use that. But we can't, it's out of question to change gcc symlink from other packages, without using alternatives. So, we'll have to resort to (5)-plain with uneasthetic *.real names. ;-)

6) Another solution if we want to make it work with update-alternatives is to parse /var/lib/rpm/alternatives/<alternative_config> from colorgcc. This is insane but doable.