RFE: add buildsys-build to comps, add buildsys macros to epel-release
opensource at till.name
Thu Jun 4 07:53:55 UTC 2009
On Wed June 3 2009, Dennis Gilmore wrote:
> On Tuesday 02 June 2009 02:38:53 pm Till Maas wrote:
> > On Monday 01 June 2009 15:49:20 Jeff Sheltren wrote:
> > > On May 26, 2009, at 5:08 AM, Till Maas wrote:
> > There is one:
> > http://cvs.fedoraproject.org/viewvc/comps/comps-el5.xml.in?view=log
> > I just created the buildsys-build group from the contents of the
> > buildsys- build package I have. Btw. who maintains the package list for
> > EPEL? I noticed it differs from the F11 one.
> It is maintainer managed the same as fedora. if no one updates it that it
> doesnt get updated. if you want you packages listed its up to you to add
I meant the package list of the minimum build root. For the Fedora Collection
afaik rel-eng maintains it. Somebody is probably doing the same for EPEL.
> > > > 2) Add the rpm macros from
> > > > http://buildsys.fedoraproject.org/buildgroups/rhel5/i386/buildsys-
> > > > macros-5-4.el5.noarch.rpm
> im honestly not sure if we should add the macros to epel-release it would
> mean then that you must have epel enabled in your mock config to build for
> EL-4 and EL-5. it would also mean that we need to have mock updated for all
> active releases with new epel configs since the existing configs would be
> broken. which would need to be tightly controlled. since epel-testing or
> epel building would be broken during the stages of transition. mock could
> be useful for people building things for rhel but not epel. if Red Hat
> decides to add them to redhat-release or centos adds them to centos-release
> we will end up with conflicts (im not aware of any plans to add them but im
> not really in the know) however it is really the right place for them.
> though we could possibly get away with making the comps group require
> epel-release and not buildsys-macros.
I already made the comps group require epel-release and not buildsys-macros.
Also there is no need to remove the groups repo at the specified URL,
therefore nothing should break during the transisiton and also old configs
will still work. We can first update epel-release and once it is in stable
update the mock config files. The problem with conflicts between EPEL and
future releases of RHEL exists with every package in EPEL, therefore it is not
a big problem.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: This is a digitally signed message part.
More information about the epel-devel-list