On 11/12/06, Jeff Spaleta <jspaleta@xxxxxxxxx> wrote:
> Or maybe we could just fix the build system. Any new > update generated by the build system that isn't installable due to > dependencies should be put in a temporary place until the dependent > packages arrive. I don't know if this is feasible or not. I'd be concerned that such a situation would make it easier for maintainers to forget about rebuilding, if there isn't public pressure to clean up the tree in a timely manner. If the staging area lets built packages from maintainer A fester outside of general availability for long periods of time due to inaction from maintainer B we are actually de-valuing the effort made by maintainer A to get packages out to chew on. These issues however can be addressed with the appropriate level of script logic to inform the general community what was built and held back. Also scripts to ensure cross-maintainer notification so that a maintainer for a library can be informed as to exactly why her library is being held back.
Sounds like a good solution to that concern.
Additionally any pre-publish staging area would have to be mirrored and accessible to anyone else in the community who need to track packages in rawhide. People working on extras-development packages would need to have reasonable access to this staging area to run mock based local builds against on their own computers. If a library packages lingers in a private staging area because one app in Core hasn't been rebuilt against it yet... that could seriously impact the abiliity of multiple application maintainers in Extras to rebuild in a timely manner.
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). So far I've mainly considered what to do if a new package requires something that doesn't exist (or requires a higher version than is currently provided). 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? n0dalus. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
