Re: gimp-print-cups

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Fedora Users]     [Fedora Development]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux