>>>> "DL" == Dave Love
DL> In preparing the recipe with the minimal spec to demonstrate, I
DL> realized it's because it doesn't work if you have scl build stuff
Yep, it explicitly gets out of the way if the SCL stuff is there. This
is to avoid bugs in the SCL macros.
DL> I wonder if it would be better -- at least more obvious!
DL> -- to have it conflict with the scl macros package.
That would be absolutely terrible, not to mention forbidden by the
packaging guidelines. Since epel-rpm-macros is in the buildroot, this
would render it impossible to build SCL packages in mock or copr or
If you have a build dependency on the SCL tools then you're obviously
not building for EPEL, and building locally doesn't necessarily ever
give you the same behavior as building in mock, so...
The best I could do is emit some kind of warning, but I'm not sure
that's even worth it. The behavior is documented in the actual macro.
DL> Will the scl bug mentioned not be fixed?
That would be up to whoever maintains the SCL macros. They are very
fragile and can't handle even the single simple redifinition that makes
%license to work. They're written in a way that makes it obvious that
someone was just trying to get something which did what they want, not
trying to make something which is readable or understandable.