Search on all SPEC files in Factory gives me 295 files with [@BUILD\_FLAVOR](https://build.opensuse.org/users/BUILD_FLAVOR)@ string.
I care mostly about many packages in d:l:python and d:l:lua which use multibuild to avoid build cycles (e.g., python-pip). Or almost all lua-* packages (e.g., lua-argparse), where we have multiple packages for multiple versions of Lua interpreter.
Mixing cleanups with actual changes isn't the best way to get your changes reviewed quickly.
Anyway, a quick look at your patch reveals 3 problems:
1* You claim that the patch is (or will be) upstream while you didn't know if that would be the case, and as it turns out, it will not.
2* The name "second_option.patch" is among the poorest patch file names possible. It only makes sense in the context of the upstream bug report where you first proposed a different implementation. But even then, the patch file name should reflect what the patch is doing, which isn't the case at all here. Imagine maintaining a package where all patches have a name that says nothing about what the patch is doing? Good luck.
3* Your patch is not replacing @BUILD_FLAVOR@ with the build flavor string as you claim. It is replacing every sequence of non-space characters surrounded by "@" with the build flavor string. So it has the potential for actually breaking things.
You insist that I should take your patch, both in SUSE and upstream, and that I should be doing that quickly. But at the same time your submission is rather poor quality, I'm sorry to say.
So I'm just not going to take that, sorry. My advice is that you write yourself a small wrapper script around quilt setup to do what you need, and work together with the BuildService team to come up with a better, standard, rpm-compliant way to declare multi-flavor packages. That I would be willing to accept upstream.
So, I guess, you are going to reject this, right?
Please point me to your most simple package which uses this mechanism.
Search on all SPEC files in Factory gives me 295 files with
[@BUILD\_FLAVOR](https://build.opensuse.org/users/BUILD_FLAVOR)@string.I care mostly about many packages in d:l:python and d:l:lua which use multibuild to avoid build cycles (e.g.,
python-pip). Or almost alllua-*packages (e.g.,lua-argparse), where we have multiple packages for multiple versions of Lua interpreter.@jdelvare You have two examples here, what’s missing?
@jdelvare: review reminder
Mixing cleanups with actual changes isn't the best way to get your changes reviewed quickly.
Anyway, a quick look at your patch reveals 3 problems: 1* You claim that the patch is (or will be) upstream while you didn't know if that would be the case, and as it turns out, it will not. 2* The name "second_option.patch" is among the poorest patch file names possible. It only makes sense in the context of the upstream bug report where you first proposed a different implementation. But even then, the patch file name should reflect what the patch is doing, which isn't the case at all here. Imagine maintaining a package where all patches have a name that says nothing about what the patch is doing? Good luck. 3* Your patch is not replacing @BUILD_FLAVOR@ with the build flavor string as you claim. It is replacing every sequence of non-space characters surrounded by "@" with the build flavor string. So it has the potential for actually breaking things.
You insist that I should take your patch, both in SUSE and upstream, and that I should be doing that quickly. But at the same time your submission is rather poor quality, I'm sorry to say.
So I'm just not going to take that, sorry. My advice is that you write yourself a small wrapper script around quilt setup to do what you need, and work together with the BuildService team to come up with a better, standard, rpm-compliant way to declare multi-flavor packages. That I would be willing to accept upstream.