Cristian Le

> > Problem would be with regex groups (named/unnamed). I think that's an important feature to support for this. > > @LecrisUT No idea what what those are. Any chance...

Could be a race condition. Packit uses the merge commit and not the source commit iirc. But the srpm should be the same for all builds so not quite sure

What about also having the opposite? I.e. marking a `file.fmf` as non-leaf. I was thinking if this might be necessary in the context of: https://github.com/teemtee/fmf/blob/29190c78e4065adf98cbb3ccf747b01973d761e2/fmf/base.py#L812-L815 --- More specifically, in https://github.com/LecrisUT/tmt-copr/issues/2...

> not sure what to do if more are present Not sure what you mean here. It would have the same inheritance rules, i.e. anything within that file is marked...

> Currently this produces leaf /, non-leaves /foo and /bar. You mean the opposite right? non-leaf `/` and `/foo`, `/bar` are leaves (in the current implementation, and discussion does not...

Oh, thanks for the info. Than the only other part of the issue is if there are tests that cover the plain order, the order with inheritance and the order...

Could break backwards compatibility, but I think this is quite a niche usage, we could just scrape the public `.fmf` files and announce the change there. Edit: as far as...

I think this should be better handled in `tmt` and have `fmf` be more specific. One way would be to expose a plugin for the `+/-` operators that the specific...

> What you mean by "Currently this can be circumvented by making the discover+: be a list."? There is no way how to add / change attribute of discover phase,...

> We need to be able to build on epel-9 which fails now (very likely contains too old macros/utils). Indeed, I was just about to look into that. I was...