On Tue, 28 Jan 2020 at 10:53, Richard W.M. Jones <rjones(a)redhat.com> 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-whic...
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]