On Mon, Oct 28, 2019 at 4:11 PM Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > > 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. This is already planned (and implemented[1] in libmodulemd). The MBS has it on their roadmap[2] to deliver "soon", but I forget if that's "by the end of the calendar year" or "first quarter of next year" off the top of my head. CCing Matthew Prahl to clarify. In short, we absolutely agree with you. Buildorder was determined early on to be a bad way to go about it, but it hadn't risen to the top of the priority queue yet. [1] https://github.com/fedora-modularity/libmodulemd/pull/244 [2] https://pagure.io/fm-orchestrator/issue/1216 _______________________________________________ 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
