Keeping old versions of packages

[Kevin Kofler]

Richard Hughes wrote:
> Not true for the majority of GNOME and KDE packages. You can't test
> gnome-control-center 3.9.1 without installing gnome-settings-daemon
> 3.9.1 as well. Not because of any library interface issue, but because
> g-s-d provides the D-Bus API used by g-c-c. The desktop, like it or
> not, is getting more monolithic, not less. FWIW, that's a totally good
> thing.

Speaking of KDE because that's what I'm familiar with:

* The KDE version upgrades are already being pushed as groups. All the 
4.10.2 packages are in a single update in Bodhi. That makes a lot of sense 
because upstream releases them together at the same time. So doing monthly 
batching in Fedora will only mean we'll be out of sync with upstream, it 
would not provide any grouping that is not already being done.

* In KDE land, you can actually use old kde* on new kdelibs (at least you 
should be able to; it's not really tested or supported for the core KDE 
packages because they are updated at the same time as kdelibs and thus 
expected to be used together), but not new kde* on old kdelibs. So it would 
be possible to test the updated packages separately in reverse dependency 
order. It's just neither practical (time-wise) nor necessary. The monthly 
grouping is already done by upstream there.

* KDE is getting less monolithic, not more. KDE Frameworks 5 will even be 
taking the splitting to extreme levels.


Basically, where upstream releases a large set of version updates 
simultaneously (e.g. KDE coordinated releases), we are already pushing them 
as one group and downstream batching would bring no benefits whatsoever, 
whereas for small leaf packages (e.g. colord-kde), the updates can easily be 
tested in isolation (even much better than when mixed with a huge batch of 
mostly unrelated changes; if, say, a batch of colord + kdelibs + colord-kde 
breaks colord-kde, how do we know which updated package broke it?).

        Kevin Kofler