12:03 a.m.
I admit I haven't been following all the EPEL discussion that closely,
so sorry if this has been brought up before...
Originally I thought EPEL was going to function more like how
centos.karan.org did, by just rebuilding Extras rpms on a ELx box, and
people would volunteer to fix any packages that wouldn't build
correctly. But it seems to be more focused on taking stable versions
and only applying security patches...which is good, especially if there
are lots of volunteers.
But I was wondering if there is room in the plans for a "EPEL-unstable"
repository (or something like that), which is just an automatic rebuild
of Fedora Extras 6 packages. For instance I need ~15 php-pear-??? rpms
for EL5 that I just rebuilt from the Fedora Extras 6 sources - no
modifications to the spec files needed.
By the way, I am not an Extras contributor, so I don't think I'd be
allowed to be a maintainer just for EPEL, would I?
Thanks,
Greg
12:46 a.m.
On 07.03.2007 07:03, Greg Swallow wrote:
[...]
But I was wondering if there is room in the plans for a "EPEL-unstable"
repository (or something like that), which is just an automatic rebuild
of Fedora Extras 6 packages. For instance I need ~15 php-pear-??? rpms
for EL5 that I just rebuilt from the Fedora Extras 6 sources - no
modifications to the spec files needed.
My 2 cent: It would IMHO make a lot more sense to have a second repo
that replaces stuff from the base or installs newer versions of gtk2 in
parallel to the one from the base; that would allow to ship newer
version of other programs that depend on newer system library, too.
But I'd say EPEL should focus on bringing up the main repo that doesn't
replace stuff now before thinking about thinks like that. And the Fedora
project is probably not the best place for this effort, too -- but I'm
optimistic that there will soon be another project where this will be
fitting in (more news to come, just be a bit patient for some weeks).
By the way, I am not an Extras contributor, so I don't think
I'd be
allowed to be a maintainer just for EPEL, would I?
You can become a Extras contributor via the normal sponsorship way and
thus become a EPEL contributor, too.
There are also talks to get new contributors in as co-maintainers, that
have no access to the buildsys in the beginning. But we probably need
some technical infrastructure for that, that is not yet in place.
CU
thl
12:52 a.m.
Thorsten Leemhuis wrote:
On 07.03.2007 07:03, Greg Swallow wrote:
> [...]
> But I was wondering if there is room in the plans for a
> "EPEL-unstable" repository (or something like that), which is just an
> automatic rebuild of Fedora Extras 6 packages. For instance I need
> ~15 php-pear-??? rpms for EL5 that I just rebuilt from the Fedora
> Extras 6 sources - no modifications to the spec files needed.
My 2 cent: It would IMHO make a lot more sense to have a second repo
that replaces stuff from the base or installs newer versions of gtk2
in parallel to the one from the base; that would allow to ship newer
version of other programs that depend on newer system library, too.
But I'd say EPEL should focus on bringing up the main repo that
doesn't replace stuff now before thinking about thinks like that. And
the Fedora project is probably not the best place for this effort, too
-- but I'm optimistic that there will soon be another project where
this will be fitting in (more news to come, just be a bit patient for
some weeks).
I wasn't suggesting replacing stuff in the base at all, I just thought
having more packages from Extras (all that will just rebuild without
changes) available right away for EL5 would be nice, whether it is
sponsored by Fedora or a 3rd party.
Greg
1:03 a.m.
Greg Swallow a écrit :
of Fedora Extras 6 packages. For instance I need ~15 php-pear-???
rpms
for EL5 that I just rebuilt from the Fedora Extras 6 sources - no
modifications to the spec files needed.
I'm probably the maintener of some of them and i will like to push them
on EPEL soon... (i need some time to prepare my build machine for my tests).
Some of them are really useful (i think) because they were provided by
old php version (bundle with), so EL4 -> EL5 mays requires then.
Christopher Stone (maintener for most of the others) haven't put his
status on http://www.fedoraproject.org/wiki/EPEL/ContributorStatus.
Actually i'm waiting for a "green light" to begin the push...
Regards
1:06 a.m.
Remi Collet wrote:
Greg Swallow a écrit :
> of Fedora Extras 6 packages. For instance I need ~15 php-pear-??? rpms
> for EL5 that I just rebuilt from the Fedora Extras 6 sources - no
> modifications to the spec files needed.
>
I'm probably the maintener of some of them and i will like to push them
on EPEL soon... (i need some time to prepare my build machine for my tests).
Some of them are really useful (i think) because they were provided by
old php version (bundle with), so EL4 -> EL5 mays requires then.
Yes, I actually reported that as a bug in RHEL5 but was told to read the
release notes - list of the missing ones in this bug report:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=218220
Christopher Stone (maintener for most of the others) haven't put
his
status on http://www.fedoraproject.org/wiki/EPEL/ContributorStatus.
Actually i'm waiting for a "green light" to begin the push...
Sounds good. So just curious, what will be your philosophy in updating
the EL5 rpms vs say the FC6 rpms? Do you think you will just rebuild
the same versions at the same time? Or maybe update the FC6 rpm a
week/month before the EL5 rpm (assuming the update is new features, not
security)?
Greg
1:20 a.m.
On 07.03.2007 07:52, Greg Swallow wrote:
Thorsten Leemhuis wrote:
> On 07.03.2007 07:03, Greg Swallow wrote:
>> [...]
>> But I was wondering if there is room in the plans for a
>> "EPEL-unstable" repository (or something like that), which is just an
>> automatic rebuild of Fedora Extras 6 packages. For instance I need
>> ~15 php-pear-??? rpms for EL5 that I just rebuilt from the Fedora
>> Extras 6 sources - no modifications to the spec files needed.
> My 2 cent: It would IMHO make a lot more sense to have a second repo
> that replaces stuff from the base or installs newer versions of gtk2
> in parallel to the one from the base; that would allow to ship newer
> version of other programs that depend on newer system library, too.
> But I'd say EPEL should focus on bringing up the main repo that
> doesn't replace stuff now before thinking about thinks like that. And
> the Fedora project is probably not the best place for this effort, too
> -- but I'm optimistic that there will soon be another project where
> this will be fitting in (more news to come, just be a bit patient for
> some weeks).
I wasn't suggesting replacing stuff in the base at all,
I know.
I just thought
having more packages from Extras (all that will just rebuild without
changes) available right away for EL5 would be nice, whether it is
sponsored by Fedora or a 3rd party.
Ohh, okay, then I got your wrong (I thought you wanted to constantly and
automatically rebuild FE6 for EPEL5).
My idea is to have most of Fedora Extras 6 packages available for EPEL5
soon. But it's not a automatic rebuild -- remember, someone has to
maintain the stuff for quite some time, so we'll only build packages
that have EPEL-maintainers. But I'm optimistic that with this way and a
bit of co-maintainership we should be able to have most of FE6 available
in EPEL5 soon.
CU
thl
1:25 a.m.
On 07.03.2007 08:03, Remi Collet wrote:
Greg Swallow a écrit :
> of Fedora Extras 6 packages. For instance I need ~15 php-pear-??? rpms
> for EL5 that I just rebuilt from the Fedora Extras 6 sources - no
> modifications to the spec files needed.
I'm probably the maintener of some of them and i will like to push them
on EPEL soon... (i need some time to prepare my build machine for my tests).
Some of them are really useful (i think) because they were provided by
old php version (bundle with), so EL4 -> EL5 mays requires then.
Christopher Stone (maintener for most of the others) haven't put his
status on http://www.fedoraproject.org/wiki/EPEL/ContributorStatus.
Actually i'm waiting for a "green light" to begin the push...
I'll work on a package maintainer policy today/tomorrow that lays down
what kind of version-update policy we actually want for EPEL to avoid
that we end up with a EPEL4 that has some brand new packages while
others are quite old. I hope to discuss this policy then on this list
and make something effective after next Sundays EPEL-SIG meeting.
For EPEL5 it's probably not that pressuring, but needed quite soon, too.
I'd say what's now in FE6 is suitable for EPEL5. There will probably a
public CentOS 5 beta soon that we can use for testing.
CU
thl
1:47 a.m.
Greg Swallow a écrit :
I actually reported that as a bug in RHEL5 but was told to read the
release notes - list of the missing ones in this bug report:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=218220
Thank's for the link.
It's the first reason why i became a contributor :
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190066
Sounds good. So just curious, what will be your philosophy in
updating
the EL5 rpms vs say the FC6 rpms? Do you think you will just rebuild
the same versions at the same time? Or maybe update the FC6 rpm a
week/month before the EL5 rpm (assuming the update is new features, not
security)?
In the near future, FC6 could be the testing branch for EPEL, but when
it become EOL (F8), i'll have to think to another way...
php-pear are noarch but could have requires on php or pear version.
I don't know which pear version will be on RHEL5. Hopes for 1.5.0,
because 1.4.x has some problems with packaging
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197940
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=222557
Of course analysing each Changelog is the first thing i always do.
For example, php-pecl-zip would have been stick on 1.5.0 when 1.6.0 have
change the class name (it's just an example, i don't know if zip is
bundled with php on RHEL5).
My biggest chalenge will be to create patch to an old version when a new
version isn't compatible (API changes) but bugs are filed.
Of course, i'm waiting for (and will try to follow) the official policy
about version update on EPEL.
Remi.
P.S. hope my english is readable...
3:09 a.m.
On Wed, Mar 07, 2007 at 08:20:45AM +0100, Thorsten Leemhuis wrote:
Ohh, okay, then I got your wrong (I thought you wanted to constantly and
automatically rebuild FE6 for EPEL5).
My idea is to have most of Fedora Extras 6 packages available for EPEL5
soon. But it's not a automatic rebuild -- remember, someone has to
maintain the stuff for quite some time, so we'll only build packages
that have EPEL-maintainers. But I'm optimistic that with this way and a
bit of co-maintainership we should be able to have most of FE6 available
in EPEL5 soon.
I think that it would be nice to have automatic rebuild of F6 for the packages
that are not in EPEL nor RHEL (in another repo, of course). That way
the packages that change too often to be in EPEL and that don't have a
maintainer close enough to upstream to know about what backport should
be done could still be available. For a personnal example (always the
same ;-) there is libdap. It works well with http://centos.karan.org/.
There should then be a long term solution to extend this when F6 is
dropped, but it would be in years, so we'll be able to see if such a
repo is really necessary.
--
Pat
6:24 p.m.
On Tue, 2007-03-06 at 22:03 -0800, Greg Swallow wrote:
I admit I haven't been following all the EPEL discussion that
closely,
so sorry if this has been brought up before...
Just to be really late to the party:
But I was wondering if there is room in the plans for a
"EPEL-unstable"
repository (or something like that), which is just an automatic rebuild
of Fedora Extras 6 packages. For instance I need ~15 php-pear-??? rpms
for EL5 that I just rebuilt from the Fedora Extras 6 sources - no
modifications to the spec files needed.
It would be very interesting to have a uniform way to provide RHEL-addon
packages that are unsupported. This would help people who want to
evaluate things on RHEL that are available on Fedora, but aren't in a
state that can be supported by EPEL's or RHEL's standards.
I would like to point people to a standard repo for those things, and
have them know that the packages were built in a sane way (because they
went through the build system) w/o making any guarantees in terms of API
stability etc. What I, and I suspect others, do right now is to build
such packages whichever way we see fit, and then push them to a custom
yum repo on people.redhat.com or et.redhat.com or ... As a case in
point, I rebuild several of the packages I maintain for Fedora for RHEL4
and RHEL5, and people seem to be using them. This is particularly useful
for RHEL4, where the rebuild might require small tweaks to the specfile.
David
1:38 p.m.
On Fri, Mar 16, 2007 at 04:24:36PM -0700, David Lutterkort wrote:
On Tue, 2007-03-06 at 22:03 -0800, Greg Swallow wrote:
> I admit I haven't been following all the EPEL discussion that closely,
> so sorry if this has been brought up before...
Just to be really late to the party:
> But I was wondering if there is room in the plans for a "EPEL-unstable"
> repository (or something like that), which is just an automatic rebuild
> of Fedora Extras 6 packages. For instance I need ~15 php-pear-??? rpms
> for EL5 that I just rebuilt from the Fedora Extras 6 sources - no
> modifications to the spec files needed.
It would be very interesting to have a uniform way to provide RHEL-addon
packages that are unsupported. This would help people who want to
evaluate things on RHEL that are available on Fedora, but aren't in a
state that can be supported by EPEL's or RHEL's standards.
Then better massage them to meet those standards?
Of course, you still need to define what those standards are, which is
somehow blurry ATM. We all have a feeling when a Fedora package is
suitable for RHEL or not, but there are no criteria written down as of
yet.
--
Axel.Thimm at ATrpms.net
1:01 p.m.
On Sat, 2007-03-17 at 19:38 +0100, Axel Thimm wrote:
> It would be very interesting to have a uniform way to provide
RHEL-addon
> packages that are unsupported. This would help people who want to
> evaluate things on RHEL that are available on Fedora, but aren't in a
> state that can be supported by EPEL's or RHEL's standards.
Then better massage them to meet those standards?
It's mainly an issue of how fast those projects change upstream and how
mature they are, not so much one of packaging. I.e., you want to make it
easy to try them out on RHEL even when you know that they change too
rapidly to guarantee API stability etc.
David
3:41 p.m.
On Mon, Mar 19, 2007 at 06:01:33PM +0000, David Lutterkort wrote:
On Sat, 2007-03-17 at 19:38 +0100, Axel Thimm wrote:
> > It would be very interesting to have a uniform way to provide RHEL-addon
> > packages that are unsupported. This would help people who want to
> > evaluate things on RHEL that are available on Fedora, but aren't in a
> > state that can be supported by EPEL's or RHEL's standards.
>
> Then better massage them to meet those standards?
It's mainly an issue of how fast those projects change upstream and how
mature they are, not so much one of packaging. I.e., you want to make it
easy to try them out on RHEL even when you know that they change too
rapidly to guarantee API stability etc.
If it's that experimental and changing then perhaps it's better off in
some packager's private repo like p.r.c etc.?
Otherwise putting it in a repo where we usually put stuff for doing QA
for either updates for the current RHEL release ("updates-testing") or
even for an upcoming ("rawhide") would not be that good, as we'd like
to draw testers to these repos.
Just to get the picture about what degree of maturity you are
targeting: Where would you place such projects if it were about Fedora
and not RHEL? Rawhide, current Fedora release or not at all?
--
Axel.Thimm at ATrpms.net
6:10 p.m.
On Mon, 2007-03-19 at 21:41 +0100, Axel Thimm wrote:
If it's that experimental and changing then perhaps it's
better off in
some packager's private repo like p.r.c etc.?
That's what I (and lots of others) are doing currently. The point of
what I am talking about is to help users by removing the need to chase
lots of different repos.
Just to get the picture about what degree of maturity you are
targeting: Where would you place such projects if it were about Fedora
and not RHEL? Rawhide, current Fedora release or not at all?
Rawhide and current Fedora release. The stumbling stone for what I am
talking about compared to the EPEL discussions so far is the long-term
support and API guarantees; in other words, people that use these
packages can expect them to work at a level similar to Fedora packages,
but will need to be prepared for some churn and possibly incompatible
changes.
David
6241
days inactive
6253
days old
epel-devel@lists.fedoraproject.org
13 comments
6 participants
participants (6)
-
Axel Thimm -
David Lutterkort -
Greg Swallow -
Patrice Dumas -
Remi Collet -
Thorsten Leemhuis