On 11/11/06, n0dalus <n0dalus+redhat@xxxxxxxxx> 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
