epel-release: consider adding %epel macro ?

[Rex Dieter]

I'd like to be able to conditionalize some package features depending on if 
epel repo is enabled or not.  One way to accomplish that goal is if epel-
release defined some macro, say, something like %{epel}, similar to 
%{feodra} or %{rhel}

(I don't care what the macro is named, as long as the bikeshed remains blue)

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.

thoughts?

-- Rex

[Rex Dieter]

Rex Dieter wrote on Oct 16:
> I'd like to be able to conditionalize some package features depending on
> if
> epel repo is enabled or not.  One way to accomplish that goal is if epel-
> release defined some macro, say, something like %{epel}, similar to
> %{feodra} or %{rhel}
>
> (I don't care what the macro is named, as long as the bikeshed remains
> blue)
>
> 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.
>
> thoughts?

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.

-- Rex

[Jeff Sheltren]

On Mon, Oct 20, 2014 at 3:11 PM, Rex Dieter  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?

-Jeff

[Rex Dieter]

Jeff Sheltren wrote:
> On Mon, Oct 20, 2014 at 3:11 PM, Rex Dieter
>  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.

-- Rex

[Chuck Anderson]

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
> >  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?

[Rex Dieter]

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
> > >  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

[Rex Dieter]

Rex Dieter wrote:
> Rex Dieter wrote on Oct 16:
> > I'd like to be able to conditionalize some package features depending on
> > if
> > epel repo is enabled or not.  One way to accomplish that goal is if epel-
> > release defined some macro, say, something like %{epel}, similar to
> > %{feodra} or %{rhel}
> >
> > (I don't care what the macro is named, as long as the bikeshed remains
> > blue)
> >
> > 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.
> >
> > thoughts?
>
> 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.

Here's the epel-release patch as promised (epel7 branch), attached.

-- Rex

[Rex Dieter]

Rex Dieter wrote:
> +%epel %{?rhel}%{!?:rhel:7}

typo alert ^^ (in the second part), but hopefully you get the idea.

Or, if you'd rather not depend on %rhel macro, and just hard-code to 7, that 
would be fine too.

-- Rex

[Jeff Sheltren]

On Fri, Oct 31, 2014 at 5:42 AM, Rex Dieter  wrote:
> Rex Dieter wrote:
> > +%epel %{?rhel}%{!?:rhel:7}
>
> typo alert ^^ (in the second part), but hopefully you get the idea.
>
> Or, if you'd rather not depend on %rhel macro, and just hard-code to 7,
> that
> would be fine too.

The approach looks good to me.

The patch needs a little work though: besides the typo you mentioned, the
install line is copying the wrong SOURCE file.

I see %rhel is present on CentOS -- I can't speak to other rebuilds though.
It would be nice to verify that.

Bonus points for a second patch to remove all the extra trailing whitespace
happening in this spec :)

-Jeff

[Rex Dieter]

Jeff Sheltren wrote:
> On Fri, Oct 31, 2014 at 5:42 AM, Rex Dieter
>  wrote:
> > Rex Dieter wrote:
> > > +%epel %{?rhel}%{!?:rhel:7}
> >
> > typo alert ^^ (in the second part), but hopefully you get the idea.
> >
> > Or, if you'd rather not depend on %rhel macro, and just hard-code to 7,
> > that
> > would be fine too.
>
> The approach looks good to me.
>
> The patch needs a little work though: besides the typo you mentioned, the
> install line is copying the wrong SOURCE file.
>
> I see %rhel is present on CentOS -- I can't speak to other rebuilds
> though. It would be nice to verify that.
>
> Bonus points for a second patch to remove all the extra trailing
> whitespace happening in this spec :)

OK (attached).

-- Rex

[Adam Miller]

On Tue, Nov 11, 2014 at 2:00 PM, Rex Dieter  wrote:
> Jeff Sheltren wrote:
> > On Fri, Oct 31, 2014 at 5:42 AM, Rex Dieter
> >  wrote:
> > > Rex Dieter wrote:
> > > > +%epel %{?rhel}%{!?:rhel:7}
> > >
> > > typo alert ^^ (in the second part), but hopefully you get the idea.
> > >
> > > Or, if you'd rather not depend on %rhel macro, and just hard-code to 7,
> > > that
> > > would be fine too.
> >
> > The approach looks good to me.
> >
> > The patch needs a little work though: besides the typo you mentioned, the
> > install line is copying the wrong SOURCE file.
> >
> > I see %rhel is present on CentOS -- I can't speak to other rebuilds
> > though. It would be nice to verify that.
> >
> > Bonus points for a second patch to remove all the extra trailing
> > whitespace happening in this spec :)
>
> OK (attached).

+1 (FWIW)

-AdamM
> -- Rex
> _______________________________________________
> epel-devel mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/epel-devel

[Kevin Fenzi]

On Tue, 11 Nov 2014 14:00:18 -0600
Rex Dieter  wrote:
> OK (attached).

The macros.epel file is missing?

kevin

[Jeff Sheltren]

On Sat, Nov 15, 2014 at 10:55 AM, Kevin Fenzi  wrote:
> The macros.epel file is missing?
>
> kevin

Looks like it didn't make it in the latest patch, but here it is from the
first patch:

----------
diff --git a/macros.epel b/macros.epel
new file mode 100644
index 0000000..fb4413f
--- /dev/null
+++ b/macros.epel
@@ -0,0 +1,3 @@
+# epel macros
+
+%epel %{?rhel}%{!?:rhel:7}
----------

Rex, does that need to change at all?

-Jeff

[Rex Dieter]

Jeff Sheltren wrote:
> On Sat, Nov 15, 2014 at 10:55 AM, Kevin Fenzi
>  wrote:
> > The macros.epel file is missing?
> >
> > kevin
>
> Looks like it didn't make it in the latest patch, but here it is from the
> first patch:
>
> diff --git a/macros.epel b/macros.epel
> new file mode 100644
> index 0000000..fb4413f
> --- /dev/null
> +++ b/macros.epel
> @@ -0,0 +1,3 @@
> +# epel macros
> +%epel %{?rhel}%{!?:rhel:7}
>
> Rex, does that need to change at all?

No change, that's good (sorry).

-- Rex

[Rex Dieter]

Rex Dieter wrote:
> I'd like to be able to conditionalize some package features depending on
> if
> epel repo is enabled or not.  One way to accomplish that goal is if epel-
> release defined some macro, say, something like %{epel}, similar to
> %{feodra} or %{rhel}
>
> (I don't care what the macro is named, as long as the bikeshed remains
> blue)
>
> 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.

As a followup, it would appear that COPR is starting to define macros:
copr_projectname
copr_username
(as well as redefining 'vendor')

So the urgency to do this in epel specifically is less, but I still think it 
is a good idea.

-- Rex

[Rex Dieter]

Rex Dieter wrote:
> I'd like to be able to conditionalize some package features depending on
> if
> epel repo is enabled or not.  One way to accomplish that goal is if epel-
> release defined some macro, say, something like %{epel}, similar to
> %{feodra} or %{rhel}

Followup, after poking nirik recently on irc, I agreed to commit it, and 
what we have is currently in -testing:

https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-4220

(luck was with me, I again committed an error/typo on my first try, but the 
-5 release there now should actually work)

-- Rex