Backwards incompatible change: PowerDNS (2.9.x to 3.1.x)

Gary T. Giesen giesen at snickers.org
Wed Nov 28 16:07:11 UTC 2012


I'm sorry if I came off a little harsh, that was not my intent. My
intent was merely to point out there are other options, the first of
which should probably have been to ask, especially if there's any
doubt.

Obviously I appreciate the effort that goes into these packages, but I
think some steps obvious steps were overlooked when the warning signs
were there: major version number change, notes in readme about
incompatibilities, etc.

People using the repositories obviously have to do their due
dilligence when performing upgrades (especially for packages they
depend heavily on), but EPEL has been pretty good in this regard so
it's easy to fall into a fire-and-forget pattern.

I think the important thing is to learn as a group from some of these
missteps, so that EPEL can continue to be the best repository of
packages available.

GTG

On Wed, Nov 28, 2012 at 3:55 PM, Stephen John Smoogen <smooge at gmail.com> wrote:
> On 28 November 2012 08:03, Gary T. Giesen <giesen at snickers.org> wrote:
>> Fancy record support (ie URL) records are also no longer supported in
>> 3.x. Some people's businesses depend on these features, and if they
>> inadvertently upgrade it will cause downtime for zones using those
>> records. Now they've been forced to exclude pdns in their yum configs
>> so they can run a yum update without breaking their systems...
>>
>> This completely defeats the purpose of having an enterprise OS with a
>> stable set of packages...
>
> I would really like to point out a couple of things that goes with ANY
> 3rd party repository and people who use them should remember EVERY
> time they do a yum update:
>
> 0) Third party repositories are volunteer organizations which will set
> guidelines on how updates and packages will occur. Enforcement of
> those guidelines can only be proactive by community members being
> active.
> 1) Being proactive means helping to maintain packages that you use and
> testing packages before they get pushed to updates.
> 2) Problems not caught by this method will still happen but can be
> mitigated by people helping packagers and other users.
>
> This is not just an EPEL thing. RPMforge, ATrpms, Dag, CentOS Extras
> etc all run into the same issue. If you feel this is too expensive,
> then you can find services elsewhere at a cost more meeting your
> needs.
>
>
> --
> Stephen J Smoogen.
> "Don't derail a useful feature for the 99% because you're not in it."
> Linus Torvalds
> "Years ago my mother used to say to me,... Elwood, you must be oh
> so smart or oh so pleasant. Well, for years I was smart. I
> recommend pleasant. You may quote me."  —James Stewart as Elwood P. Dowd
>
> _______________________________________________
> epel-devel-list mailing list
> epel-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/epel-devel-list




More information about the epel-devel-list mailing list