On Mon, 28 Oct 2019 at 14:38, Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > On Mon, Oct 28, 2019 at 2:16 PM Zbigniew Jędrzejewski-Szmek > <zbyszek@xxxxxxxxx> wrote: > > > <SNIP> > > > *Requirement*: It must be possible for the packager to specify the order in > > > which packages must be built (and to indicate which ones can be built in > > > parallel). > > Great. We need this for buildroots and lang-stack rebuilds. Let's build > > automation which can figure out the build order from package dependencies. > > Everybody will benefit from this. > > > > Please don't ever hardcode the build order a yaml file. > > > > This was something I brought up at the beginning of the year: > https://pagure.io/fm-orchestrator/issue/1241 > > The current situation is that nobody working on MBS knows how to work > with libsolv. Igor used to be the Red Hatter who knew how to work with > it, but he no longer works there (even though he's still part of the > community). > It is more than that.. because you have no 1 Make system, no 1 language order, and a ton of other 'well to bootstrap this you need to stand on one foot and hop' issues there is not a way to automatically do this. You go by dependencies and you think X needs to be built before Y, but instead you need to build Y with C, then Y with D and then X and then Y and then X with Y. And by the time you have worked out an 'automatic' way.. X no longer needs Y but needs Z which actually needs Y but in a different order than it needed before. I have been watching people try to figure this out in some form or another since 1989, and what ends up happening is that you end up with a tool which works well for a small amount of software you completely control. It might even work if you have the same toolkits inside it.. but as soon as something completely different happens you are back to ground zero coding your tool to deal with arbitrary choices on the part of the upstream developers on what they feel needs to work with what. I think that the hard coded YAML is just saying 'ok we have a limited lifetime.. and a non-finite problem.' I may not like YAML, but it is a better decision than throwing years at a problem that teams of PhD's have not seemed to finally solved in the last 30 years. <SNIP> -- Stephen J Smoogen. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
