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 <mru...@matthias-runge.de>
<mru...@fedoraproject.org>
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
