On Mon, Oct 28, 2019 at 03:11:13PM -0400, Stephen John Smoogen wrote: > 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. In the module files I have seen, the build order was generated programatically, e.g. in the rust modules. But even if it not generated automatically, then let's stick a few "build after" rules in individual packages, and not describe a build order in each module. Build order is a dependency between two packages, not a property of the thing you are building the package for. Zbyszek _______________________________________________ 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
