On Wed, 2005-02-23 at 14:11 -0500, Jef Spaleta wrote: > since this is a subpackage of gimp-print.. thats tougher. You'd have to > split this off as a new srpm. Current infrastructure constraints dictate > Extras/Core must be split at srpm level. So any subpackage that is > dropped has to be re-engineered as its own srpm to show up in Extras. > Somehow I don't get the feeling Red Hat is prepared to expend the > resources to re-engineer subpackages as new packages as general rule > when there is pressure to prune subpackages. The subpackage barrier is > somewhat problematic in this regard. In general it's hard, yes -- but I've done precisely that for the exim- doc package already. In fact the exim-doc subpackage probably shouldn't have been a subpackage of exim in the first place, because it has its own source tarballs which are updated out of sync with the program itself, and the docs go entirely into their own package. So we now have an exim-doc package which I can't build in dist-fc4, because even though it replaces an existing 'exim-doc' package in FC4, the _source_ package 'exim-doc' isn't listed. Are we going to put that back in dist-fc4 as before, or move it to Extras? I'm happy with either, but I'd like a decision. My preference would be just to put it back into dist-fc4 where it was yesterday -- because it was in FC3, and because I think it's silly for us to be busting a gut to drop just one FC4 architecture down to 4 CDs from 5, when anaconda in FC5 will make it so much easier to do this _properly_. -- dwmw2
