RFC: Rethinking EPEL at FUDcon Lawrence 2013

[Matthias Runge]

On 11/22/2012 10:56 AM, Jan Pazdziora wrote:
> 
> 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 totally agree. A more complex setup should be avoided. My intention
was to be able to upgrade packages without breaking installations of
people interested on just stable infrastructure.
> 
> 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.
> 
You're thinking about php53 also providing php = %{version}-%{release}?
Otherwise you'd produce an interesting pile of dependencies. Those
packages also need to obsolete the older packages and must be marked as
conflicting, to prevent unintentional upgrades. Did I miss something?

What about a package upgrade, which requires upgrades of several
packages? Following your proposal this IMHO makes several manual steps
necessary.
-- 
Matthias Runge <mrunge at matthias-runge.de>
               <mrunge at fedoraproject.org>