On Tue, 28 Jan 2020 at 10:53, Richard W.M. Jones <rjones@xxxxxxxxxx> wrote: > > On Tue, Jan 28, 2020 at 10:21:41AM +0100, Milan Crha wrote: > > On Tue, 2020-01-28 at 10:03 +0100, Richard W.M. Jones wrote: > > > * committing to git should build the package > > > > > > Is there a reason why this wouldn't be the case? > > > > Hi, > > the answer for the above is just your following point: > > > > > * commit groups of packages together > > > > aka the dependencies. Sometimes you want a special side tag, sometimes > > it's not needed. The way I do it right now (it's only about 4 packages > > depending on each other, not hundreds), is that I commit to master, > > then to stable, then the second package to master, to stable, then > > third and finally to the fourth and then I ran a chain-build as this: > > "a : b : c " in package 'd', (which builds 'c' and 'd' in parallel, > > once 'a' and 'b' are built in serial). Then I just refresh the koji > > build page from time to time and verify that the build still runs > > and/.or it finished successfully. I can run chain-build in stable too, > > it only needs a bit more intervention, to define overrides for 'a' and > > 'b' in bodhi, to be able to build them. > > > > I'm afraid fully automating such things might be a challenge. In other > > words, properly solving dependencies is problematic. Having yet another > > syntax to describe it, or the groups you suggest, scares me a bit. And > > we are not talking about inter-package dependencies, with packages you > > are not maintaining. > > This is not a problem - it has been solved several times > independently. I most recently proposed this, but it's certainly > isn't the first time it has been done: > > https://rwmj.wordpress.com/2020/01/14/goals-an-experimental-new-tool-which-generalizes-make/ > http://git.annexia.org/?p=fedora-ocaml-rebuild.git;a=summary > > What we need is Fedora to recognize that maintaining 100s of packages > mostly automatically should be a goal. If you look at the ecosystems > around language packaging (cpan, nodejs, crates, opam, etc) this ought > to be self-evident. When there's a unified well-organized language-specific ecosystem (and rpm-friendly; see the Java case...) it's definitely easier to do this, and yet... See [1] for example (and follow the "Homepage" button to see the tooling and setup) for an attempt to maintain thousands of packages for a particular ecosystem that is quite strict and homogeneous. And yet, as I said, many aspects of those specs wouldn't pass a package review. That said, I completely agree that "maintaining 100s of packages mostly automatically" should be a goal. Iñaki [1] https://copr.fedorainfracloud.org/coprs/iucar/cran/ _______________________________________________ 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
