Testing Fedora - small (?) suggestion.

[Jeff Spaleta]

On 11/11/06, n0dalus <n0dalus+redhat at gmail.com> wrote:
> One way of dealing with this is to put the packages in the usual spot,
> but modify createrepo to have an option to ignore packages that can't
> be installed. Or just have a subdirectory containing the packages held
> back (or even a repository).

Whatever you hold back has to be in a mirrored repository structure..
or else community build tools like mock can't see those packages and
extras maintainers won't be able to prep builds against those
packages.

> What should be done if the new package is
> installable but causes other packages to become uninstallable? We
> wouldn't usually want the new package to be held back in that case,
> but I'm not sure what the best way to handle it is -- is it ok to just
> (re)move the uninstallable package from the repository?

I bet its not generally okay to do, i bet there will be some very
interesting and significant problems with auto-removals from the
rawhide tree if you attempt that.  They only way we are going to find
out is if someone tracks the day-to-day behavior of rawhide with a toy
set of scripts and buildups an empirical understanding as to expected
gotcha situations.  It will be hard enough to make a strict holdback
mechanism work effectively.. if you also try to auto-remove items from
the tree to force consistency you risk massive cascade removals which
don't do anyone any good.... triggers and obsoletes coulld complicate
any removal logic you dream up. And again, auto-removals from Core
will add yet more complications for Extras developers who are building
Extras packages against deps in Core. If a package disappears from
Core due to an auto-removal..doesn't that automatically require a
cascade of removels for Extras packages tha depend on it...
madness...just avoid removals from the tree.

-jef"off to figure out why I can't reproduce the crash reports about
fe6 istanbul on my hardware"spaleta