On Thu, Nov 22, 2012 at 10:15:30AM +0100, Matthias Runge wrote: > > For some packages, keeping them up to date and 100% compatible to a > version released, when that package was added to EPEL is simply > impossible for volunteers. > As (bad) example, php in RHEL 6 is php-5.3.3, latest stable release is > php-5.4.8; I'm taking my hat off for everybody back-porting fixes for > every error fixed in between those releases.
[...] > To come to my proposal: > We should have something like channels, for simplicity analogous to EPEL > releases (i.e. RHEL releases). When a newer channel is opened (i.e. a > newer RHEL minor version is released), EPEL package maintainers should > be allowed to do upgrades. The schedules RHEL operates on are not necessarily aligned with the schedules of the individual components in EPEL. Having more channels / streams of EPEL could lead to unnecessary increase of work for maintainers who'd suddenly face much more complex rel-eng setup. I believe there are fundamentaly conflicting interests of different groups of people WRT the stability of the package versions vs. access to new technology. Often even a single person may have different needs and expectations from one package (I really depend on *this on* to be stable) vs. another one (upstream has these new cool features that I'd like). For your php example above, wouldn't the solution be to name one package php53, another php54, and let people happy with 5.3 stay with php53 while people who want to move on would have to knowingly replace the packages? The packages would install to the same paths so they would conflict and you'd need to pick one. In Spacewalk project, we've seen our users were recently hit by a rebase of one EPEL component that broke long-time users of the original version. We ended up having to package the original version under different name in Spacewalk (to avoid upgrade to EPEL's version by accident). Maybe if this approach became the preferred one in EPEL, to provide both versions, we could put the package to EPEL directly. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat _______________________________________________ epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list