How about, if it's not an EPEL repo, you make a separate release package for it? Just like the "epel-release" package, but pinted to your repository, so it's a separate installation and not part of EPEL? Then it would be moe like repoforge, jpackage, Percona, and Jenkins repos.
On Fri, Oct 18, 2013 at 10:03 AM, Kaleb S. KEITHLEY <kkeit...@redhat.com>wrote: > On 10/18/2013 09:55 AM, Paul Howarth wrote: > >> On 18/10/13 13:38, Kaleb S. KEITHLEY wrote: >> >>> Before too much longer I will need to withdraw the glusterfs. >>> (glusterfs-3.2.7 fwiw, very out of date, this version is a Requires for >>> another package, HekaFS.) >>> >>> Withdrawal becomes necessary when RHEL starts to ship a subset of the >>> glusterfs packages. >>> >>> But instead of withdrawing it, what if I were to alter it to simply >>> install /etc/yum.repos.d/community-**glusterfs.repo file? This repo file >>> would point to YUM repo(s) on download.gluster.org. >>> >>> Would that conform to the Fedora policy wrt not shipping packages that >>> conflict with packages in RHEL. >>> >> >> It would be against the policy of not shipping repo files for non-Fedora >> repos: >> >> https://fedoraproject.org/**wiki/Packaging:Guidelines#** >> Configuration_of_Package_**Managers<https://fedoraproject.org/wiki/Packaging:Guidelines#Configuration_of_Package_Managers> >> > > Okay, I'm okay with that. How about instead of a /etc/yum.repos.d/ file if > it's a /usr/share/doc/glusterfs.**README containing instructions for how > to use the community GlusterFS yum repo? > > -- > > Kaleb > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.**org/mailman/listinfo/devel<https://admin.fedoraproject.org/mailman/listinfo/devel> > Fedora Code of Conduct: > http://fedoraproject.org/code-**of-conduct<http://fedoraproject.org/code-of-conduct> >
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
