Chuck Anderson wrote: > On Mon, Oct 20, 2014 at 08:56:35PM -0500, Rex Dieter wrote: >> Jeff Sheltren wrote: >> >> > On Mon, Oct 20, 2014 at 3:11 PM, Rex Dieter >> > <rdie...@math.unl.edu> wrote: >> >> >> >> >> >> ping, any comment or objection? >> >> >> >> I'll work on a patch for epel-release to implement a %{epel} macro, in >> >> case anyone was waiting for implementation details. >> >> >> >> >> > Seems like it can't hurt much to have such a macro defined by the >> > epel-release package. Could you give an example of the kind of logic >> > you'd use this for? >> >> Sure. My primary motivation is that I'd like be able keep fedora/rhel >> kde >> packaging merged in fedora's git repos. *Normally*, rhel kde packaging >> disables some features ( based on %rhel macro), but I'd like to be able >> (re)enable those via some "extras" macro, like %epel. This is one >> approach redhat's kde maintainers agreed would be acceptable. > > How would enabling features at build-time contional on the presence of > epel-release and this macro help? Will you be building in two > environments and creating two repositories--one for RHEL binaries and > one for RHEL+EPEL binaries?
Yes, yes, respectively. See my first post in this thread, regarding a KDE for RHEL7 COPR. "My primary motivation is to simplify the task of doing something like: https://copr.fedoraproject.org/coprs/rdieter/kde4/ where I currently end up patching various .spec files (mostly to enable features due to having epel available), and I'd like to be able to minimize having to do that." -- Rex _______________________________________________ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel