EPEL Project collaboration and supplementary arch support

[Jim Perrin]

In preparation for the launch of EL7 and due to community demand, the
CentOS Project will be providing additional arch support not included in
RHEL. Specifically we intend to continue producing for the i686
architecture, as well as adding ARMv7 builds. These additional builds
will allow users with legacy hardware (or 32bit cloud images) to migrate
to newer versions while addressing the growing demand for ARM support.

EPEL provides a valuable resource to CentOS (and other builds), and
since a number of projects based on CentOS rely heavily on EPEL, we
would like to request that support for these additional architectures be
added to EPEL via a 'secondary arch'. This would be similar to the
Fedora distro structure regarding PPC64 and s390x, so that the impact to
the existing EPEL build structure should be minimal. Since adding arch
support can complicate packaging,  we would offer that the SIG
maintainers of these additional architectures provide assistance where
possible in the event that some packages don't build properly. I don't
want to duplicate the efforts already made by the EPEL contributors to
supplement the base packages provided in the distribution simply for
arch support, especially when much of the work is already handled via
Fedora's git infra.

Is this proposal acceptable to the EPEL devs and contributors?



-- 
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77

[Simone Caronni]

Hello,

On 18 March 2014 11:54, Jim Perrin <jperrin(a)centos.org&gt; wrote:

>  Specifically we intend to continue producing for the i686
>  architecture, as well as adding ARMv7 builds. These additional builds
>  will allow users with legacy hardware (or 32bit cloud images) to migrate
>  to newer versions while addressing the growing demand for ARM support.
>
>  EPEL provides a valuable resource to CentOS (and other builds), and
>  since a number of projects based on CentOS rely heavily on EPEL, we
>  would like to request that support for these additional architectures be
>  added to EPEL via a 'secondary arch'. 

as a contributor I would really like to have i686 as one of the main
architectures. With the current situation, there's no chance to rebuild
many of the packages that could benefit of RHEL 7 multilib support. RHEL 7
supports 32 bit programs, but we're not really able to use them in EPEL.

Quick example: I maintain Steam for Fedora, and would like to add it also
to the RPMFusion's EPEL repository; but the package is 32 bit only and
there is currently no way to package 32 bit dependencies (like SDL2) into
EPEL 7.

Previous discussion:
https://lists.fedoraproject.org/pipermail/epel-devel/2014-March/009298.html

Thanks & regards,
--Simone

-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/

[Kevin Fenzi]

On Tue, 18 Mar 2014 13:40:42 +0100
Simone Caronni <negativo17(a)gmail.com&gt; wrote:

>  as a contributor I would really like to have i686 as one of the main
>  architectures. With the current situation, there's no chance to
>  rebuild many of the packages that could benefit of RHEL 7 multilib
>  support. RHEL 7 supports 32 bit programs, but we're not really able
>  to use them in EPEL.
>  
>  Quick example: I maintain Steam for Fedora, and would like to add it
>  also to the RPMFusion's EPEL repository; but the package is 32 bit
>  only and there is currently no way to package 32 bit dependencies
>  (like SDL2) into EPEL 7. 
Yeah, in order to get there we would need to build against both i686
and x86_64 CentOS. Which we could do, but we likely want to make sure
the i686 effort is good and viable first. 

kevin

[Dennis Gilmore]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 18 Mar 2014 13:40:42 +0100
Simone Caronni <negativo17(a)gmail.com&gt; wrote:

>  Hello,
>  
>  On 18 March 2014 11:54, Jim Perrin <jperrin(a)centos.org&gt; wrote:
>  
>  > Specifically we intend to continue producing for the i686
>  > architecture, as well as adding ARMv7 builds. These additional
>  > builds will allow users with legacy hardware (or 32bit cloud
>  > images) to migrate to newer versions while addressing the growing
>  > demand for ARM support.
>  >
>  > EPEL provides a valuable resource to CentOS (and other builds), and
>  > since a number of projects based on CentOS rely heavily on EPEL, we
>  > would like to request that support for these additional
>  > architectures be added to EPEL via a 'secondary arch'.
>  
>  
>  as a contributor I would really like to have i686 as one of the main
>  architectures. With the current situation, there's no chance to
>  rebuild many of the packages that could benefit of RHEL 7 multilib
>  support. RHEL 7 supports 32 bit programs, but we're not really able
>  to use them in EPEL.
>  
>  Quick example: I maintain Steam for Fedora, and would like to add it
>  also to the RPMFusion's EPEL repository; but the package is 32 bit
>  only and there is currently no way to package 32 bit dependencies
>  (like SDL2) into EPEL 7.
>  
EPEL doesnt support multilib at all. so its really not going to help
you here.

Dennis
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (GNU/Linux)
>
> iQIcBAEBAgAGBQJTK2PWAAoJEH7ltONmPFDRtRgQAJRbeLVUl/wOb65xXf2SwBHU
> ch0+FFcL3/Ct9vJOL0P+UKjGrtbxn64nxqTAa+OV/sotvtcQcou2s3RchykFhEwG
> Jr0Tc8ERUi0/+1J8AnYrsOpvCDAULRJcLosbVLjt3Hlq35cAfiHM3pusI1/n3DK4
> YvjjYjdRlONcBGmyYEa6OAqiewjHowLrJYQK4B52zdgIFfyjYLgkYVHRlmVKNkEV
> BWxJE9k8c9r+0Zm8ctPgHUhCNSsCPmlOZ+CDcqAsmxjVYsHarveLgnzwDr/9zmlz
> ascNquBD1eDjJhhX5DrxOxvgDqY57LWZ2lumwwx9BbH0bATQAaxwqWxI8q1uUa/E
> DdRxAQkJ9thTLrPEDGK1KLpQ9oQ8xsTyAWD7kjUhsNe1+mfbnM0Ite5Fmbc2xAbg
> CKsmqi+aKNEDlgoX1E73++VoFBQcsAJJT23PsPSkb8w0lgyBUQvauqzejPO76vuY
> 5HYyObI3GiwynAXq0FrHdw4agKZ1/S87ACm1RBft/EEIZIls7SZP5jEFVHvpJGs2
> Ch5WqtM8qxp5jNPxkRJilNOVbsvrsm2+HDaSgKC/sqRfFA8Vg1zwcuaGSWVHw6ZE
> 0nPRrD+mVGN7HG4P/Pv3tZE+gXZgcLpAZWYx9o7hRw0t4lfHT6O6MTqYQf2yNVRZ
> RzUSTktvZyEOrBAWp/+L
> =pL6W
> -----END PGP SIGNATURE-----
>

[Simone Caronni]

On 20 March 2014 22:55, Dennis Gilmore <dennis(a)ausil.us&gt; wrote:

>  On Tue, 18 Mar 2014 13:40:42 +0100
>  Simone Caronni <negativo17(a)gmail.com&gt; wrote:
>  > as a contributor I would really like to have i686 as one of the main
>  > architectures. With the current situation, there's no chance to
>  > rebuild many of the packages that could benefit of RHEL 7 multilib
>  > support. RHEL 7 supports 32 bit programs, but we're not really able
>  > to use them in EPEL.
>  >
>  > Quick example: I maintain Steam for Fedora, and would like to add it
>  > also to the RPMFusion's EPEL repository; but the package is 32 bit
>  > only and there is currently no way to package 32 bit dependencies
>  > (like SDL2) into EPEL 7.
>
>  EPEL doesnt support multilib at all. so its really not going to help
>  you here.
>  
I'm not sure I got it. If I look at current EPEL 6 I have multiple
architectures in place (libvdpau example):

Installed Packages
libvdpau.x86_64                            0.7-1.el6
@epel
Available Packages
libvdpau.i686                              0.7-1.el6
epel
libvdpau-devel.i686                        0.7-1.el6
epel
libvdpau-devel.x86_64                      0.7-1.el6
epel
libvdpau-docs.noarch                       0.7-1.el6
epel

What I was saying it's that it would be nice to have the same kind of
support for EPEL 7 when CentOS i686 trees will appear.

Regards,
--Simone

-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/

[Kevin Fenzi]

On Tue, 18 Mar 2014 05:54:43 -0500
Jim Perrin <jperrin(a)centos.org&gt; wrote:

>  In preparation for the launch of EL7 and due to community demand,
> the
>  CentOS Project will be providing additional arch support not included
>  in RHEL. Specifically we intend to continue producing for the i686
>  architecture, as well as adding ARMv7 builds. These additional builds
>  will allow users with legacy hardware (or 32bit cloud images) to
>  migrate to newer versions while addressing the growing demand for ARM
>  support. 
Sounds reasonable. ;) 

>  EPEL provides a valuable resource to CentOS (and other builds), and
>  since a number of projects based on CentOS rely heavily on EPEL, we
>  would like to request that support for these additional architectures
>  be added to EPEL via a 'secondary arch'. This would be similar to the
>  Fedora distro structure regarding PPC64 and s390x, so that the impact
>  to the existing EPEL build structure should be minimal. Since adding
>  arch support can complicate packaging,  we would offer that the SIG
>  maintainers of these additional architectures provide assistance where
>  possible in the event that some packages don't build properly. I don't
>  want to duplicate the efforts already made by the EPEL contributors to
>  supplement the base packages provided in the distribution simply for
>  arch support, especially when much of the work is already handled via
>  Fedora's git infra.
>  
>  Is this proposal acceptable to the EPEL devs and contributors? 
I think this is a reasonable way forward for now. 

Short term we would need to setup a blocker bug for the arches for
those teams to watch when maintainers need help, and would need to
grant them access to make changes needed to keep things building. 

If/when things are all up and running smoothly, we could look at making
them 'primary'. 

kevin

[Jeff Sheltren]

Kevin Fenzi wrote:
>  On Tue, 18 Mar 2014 05:54:43 -0500
>  Jim Perrin <jperrin(a)centos.org&gt; wrote:
>
> > Is this proposal acceptable to the EPEL devs and contributors?
>
>  I think this is a reasonable way forward for now. 
>  
Yes, +1 to this.

-Jeff