Extras not enabled on koji?

[Richard Shaw]

I'm trying to build a package that requires swig 3.0.12+. The version in
EPEL is way too old but swig3 is provided in the extras repo.

I was able to build locally via mock and COPR fine, but when I tried
official builds it doesn't look like the "extras" repo is enabled.

Is that on purpose?

Thanks,
Richard

[Stephen John Smoogen]

On Sat, 4 Apr 2020 at 14:54, Richard Shaw <hobbes1069(a)gmail.com&gt; wrote:

>  I'm trying to build a package that requires swig 3.0.12+. The
> version in
>  EPEL is way too old but swig3 is provided in the extras repo.
>
>  I was able to build locally via mock and COPR fine, but when I tried
>  official builds it doesn't look like the "extras" repo is enabled.
>
>  Is that on purpose?
>
>  
Which extras directory and which release of EL are you talking about? The
one in CentOS is not the same as the one in RHEL and they have different
things. EPEL builds against RHEL so that might affect things.



>  Thanks,
>  Richard
>  _______________________________________________
>  epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to epel-devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]...
>  

-- 
Stephen J Smoogen.

[Richard Shaw]

On Sat, Apr 4, 2020 at 2:27 PM Stephen John Smoogen <smooge(a)gmail.com&gt;
wrote:

>  On Sat, 4 Apr 2020 at 14:54, Richard Shaw <hobbes1069(a)gmail.com&gt; wrote:
>
> > I'm trying to build a package that requires swig 3.0.12+. The version in
> > EPEL is way too old but swig3 is provided in the extras repo.
> >
> > I was able to build locally via mock and COPR fine, but when I tried
> > official builds it doesn't look like the "extras" repo is enabled.
> >
> > Is that on purpose?
> >
> >
>  Which extras directory and which release of EL are you talking about? The
>  one in CentOS is not the same as the one in RHEL and they have different
>  things. EPEL builds against RHEL so that might affect things.
>  
I use the Fedora CentOS 7 test instance as a test environment when trying
to track down available packages:

$ sudo yum list swig*
Loaded plugins: fastestmirror
Repository epel is listed more than once in the configuration
Repository epel-testing is listed more than once in the configuration
Loading mirror speeds from cached hostfile
 * base: d36uatko69830t.cloudfront.net
 * epel: mirrors.kernel.org
 * extras: d36uatko69830t.cloudfront.net
 * updates: d36uatko69830t.cloudfront.net
Available Packages
swig.x86_64                             2.0.10-5.el7
  base
swig-doc.noarch                         2.0.10-5.el7
  base
swig3.x86_64                            3.0.12-17.el7
 extras
swig3-doc.noarch                        3.0.12-17.el7
 extras
swig3-gdb.x86_64                        3.0.12-17.el7
 extras

Thanks,
Richard

[Stephen John Smoogen]

On Sat, 4 Apr 2020 at 15:29, Richard Shaw <hobbes1069(a)gmail.com&gt; wrote:

>  On Sat, Apr 4, 2020 at 2:27 PM Stephen John Smoogen
> <smooge(a)gmail.com&gt;
>  wrote:
>
> >
> > On Sat, 4 Apr 2020 at 14:54, Richard Shaw <hobbes1069(a)gmail.com&gt; wrote:
> >
> >> I'm trying to build a package that requires swig 3.0.12+. The version in
> >> EPEL is way too old but swig3 is provided in the extras repo.
> >>
> >> I was able to build locally via mock and COPR fine, but when I tried
> >> official builds it doesn't look like the "extras" repo is enabled.
> >>
> >> Is that on purpose?
> >>
> >>
> > Which extras directory and which release of EL are you talking about? The
> > one in CentOS is not the same as the one in RHEL and they have different
> > things. EPEL builds against RHEL so that might affect things.
> >
>
>  I use the Fedora CentOS 7 test instance as a test environment when trying
>  to track down available packages:
>
>  $ sudo yum list swig*
>  Loaded plugins: fastestmirror
>  Repository epel is listed more than once in the configuration
>  Repository epel-testing is listed more than once in the configuration
>  Loading mirror speeds from cached hostfile
>   * base: d36uatko69830t.cloudfront.net
>   * epel: mirrors.kernel.org
>   * extras: d36uatko69830t.cloudfront.net
>   * updates: d36uatko69830t.cloudfront.net
>  Available Packages
>  swig.x86_64                             2.0.10-5.el7
>    base
>  swig-doc.noarch                         2.0.10-5.el7
>    base
>  swig3.x86_64                            3.0.12-17.el7
>     extras
>  swig3-doc.noarch                        3.0.12-17.el7
>     extras
>  swig3-gdb.x86_64                        3.0.12-17.el7
>     extras
>
>  
OK so swig3 seems to just be in CentOS extras and not in RHEL extras.




>  Thanks,
>  Richard
>  _______________________________________________
>  epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to epel-devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]...
>  

-- 
Stephen J Smoogen.

[Richard Shaw]

On Sun, Apr 5, 2020 at 9:52 AM Stephen John Smoogen <smooge(a)gmail.com&gt;
wrote:

>  OK so swig3 seems to just be in CentOS extras and not in RHEL
> extras.
>  
Is this the way it should be? All the EPEL test instances are CentOS,
right? If I run mock it uses CentOS extra. So why would the official
builders be different?

This doesn't make for a good packager experience :)

Thanks,
Richard

[Kevin Fenzi]

On Sun, Apr 05, 2020 at 03:37:29PM -0500, Richard Shaw wrote:
>  On Sun, Apr 5, 2020 at 9:52 AM Stephen John Smoogen
> <smooge(a)gmail.com&gt;
>  wrote:
>  
>  > OK so swig3 seems to just be in CentOS extras and not in RHEL extras.
>  >
>  
>  Is this the way it should be? All the EPEL test instances are CentOS,
>  right? If I run mock it uses CentOS extra. So why would the official
>  builders be different? 
EPEL has always built against RHEL. Unfortunately we can't simply
provide RHEL free to everyone that wants to test against it, but you can
get a free developer subscription and use that. 

>  This doesn't make for a good packager experience :) 
Well, not sure how to make it better. We could move to building against
CentOS, but that would be a big undertaking and some folks would like
that and some would not. 

We could perhaps advertise the developer rhel subscription more for
testing?

Open to other ideas...

kevin

[Richard Shaw]

On Sun, Apr 5, 2020 at 5:21 PM Kevin Fenzi <kevin(a)scrye.com&gt; wrote:

>  On Sun, Apr 05, 2020 at 03:37:29PM -0500, Richard Shaw wrote:
>  > On Sun, Apr 5, 2020 at 9:52 AM Stephen John Smoogen <smooge(a)gmail.com&gt;
>  > wrote:
>  >
>  > > OK so swig3 seems to just be in CentOS extras and not in RHEL extras.
>  > >
>  >
>
>  > This doesn't make for a good packager experience :)
>
>  Well, not sure how to make it better. We could move to building against
>  CentOS, but that would be a big undertaking and some folks would like
>  that and some would not.
>
>  We could perhaps advertise the developer rhel subscription more for
>  testing?
>
>  Open to other ideas...
>  
Well I should have been more specific. What I mean by a "poort packager
experience" is about consistency. When I build the package in mock, it
built. When I built it in COPR, it built. But when I tried to build the
real package, it failed.

This may be a corner case where things are "different" but consistency *IS*
important.

Thanks,
Richard

[Stephen John Smoogen]

On Sun, 5 Apr 2020 at 19:37, Richard Shaw <hobbes1069(a)gmail.com&gt; wrote:

>  On Sun, Apr 5, 2020 at 5:21 PM Kevin Fenzi <kevin(a)scrye.com&gt;
> wrote:
>
> > On Sun, Apr 05, 2020 at 03:37:29PM -0500, Richard Shaw wrote:
> > > On Sun, Apr 5, 2020 at 9:52 AM Stephen John Smoogen <smooge(a)gmail.com&gt;
> > > wrote:
> > >
> > > > OK so swig3 seems to just be in CentOS extras and not in RHEL extras.
> > > >
> > >
> >
> > > This doesn't make for a good packager experience :)
> >
> > Well, not sure how to make it better. We could move to building against
> > CentOS, but that would be a big undertaking and some folks would like
> > that and some would not.
> >
> > We could perhaps advertise the developer rhel subscription more for
> > testing?
> >
> > Open to other ideas...
> >
>
>  Well I should have been more specific. What I mean by a "poort packager
>  experience" is about consistency. When I build the package in mock, it
>  built. When I built it in COPR, it built. But when I tried to build the
>  real package, it failed.
>
>  This may be a corner case where things are "different" but consistency
>  *IS* important.
>
>  
Yes I agree.. but we have built against RHEL for years and they do not have
this package in their extras. CentOS does have it in their Extras which is
the inconsistency. The problem is that CentOS EL5/EL6 had an Extras channel
which had updated swig and other packages in it, but RHEL-7 named one of
their channels Extras which was to have non-supported packages in it. So
both groups did something inconsistent with each other and you and us got
stuck with it.

I can't fix either CentOS or RHEL package sets or channel names. I can't
tell either of them what should be in these channels especially for
channels which are older than a year old. I can't create a consistent
package experience. I can commiserate with you and say I understand what a
frustration it is... but that is cold comfort.


-- 
Stephen J Smoogen.

[Todd Zullinger]

Stephen John Smoogen wrote:
>  On Sun, 5 Apr 2020 at 19:37, Richard Shaw
> <hobbes1069(a)gmail.com&gt; wrote:
> > This may be a corner case where things are "different" but consistency
> > *IS* important.
> >
> >
>  Yes I agree.. but we have built against RHEL for years and they do not have
>  this package in their extras. CentOS does have it in their Extras which is
>  the inconsistency. The problem is that CentOS EL5/EL6 had an Extras channel
>  which had updated swig and other packages in it, but RHEL-7 named one of
>  their channels Extras which was to have non-supported packages in it. So
>  both groups did something inconsistent with each other and you and us got
>  stuck with it.
>  
>  I can't fix either CentOS or RHEL package sets or channel names. I can't
>  tell either of them what should be in these channels especially for
>  channels which are older than a year old. I can't create a consistent
>  package experience. I can commiserate with you and say I understand what a
>  frustration it is... but that is cold comfort. 
I wonder if we (in the most general sense of we, not anyone
in particular) could come up with a script to enumerate the
differences between those two repos?  And then arrange for
packages not in both repos to be excluded from the epel mock
configs?

Maybe someone reading who has a little extra time on their
hands might find such a project interesting?  I know there
aren't usually many folks with extra time on their hands, so
I hesitate to even toss out ideas which I likely have little
time to help implement.

-- 
Todd