CentOS - Jun 2015 - Old and new package version numbers during RPM update

On 29 June 2015 at 07:37, John R Pierce <pierce at hogranch.com> wrote:
> so a regex looking for "system:" vs "system {"   should
nicely delineate
> these.   I dunno, I might even put that into the conversion utility and
> have it just quit if the file is already in the new format, and always run
> it.
>
?+1 for the idempotent approach. IMHO much more robust. Also consider what
will happen if someone does a 'yum downgrade' on the package or a
dependency -- you might want to allow the conversion to go both ways or at
least complain appropriately.

?K?

On 29/06/15 01:07, Kahlil Hodgson wrote:
> On 29 June 2015 at 07:37, John R Pierce <pierce at hogranch.com>
wrote:
> 
>> so a regex looking for "system:" vs "system {"  
should nicely delineate
>> these.   I dunno, I might even put that into the conversion utility and
>> have it just quit if the file is already in the new format, and always
run
>> it.
> 
> ?+1 for the idempotent approach. IMHO much more robust. Also consider what
> will happen if someone does a 'yum downgrade' on the package or a
> dependency -- you might want to allow the conversion to go both ways or at
> least complain appropriately.
Yep. I've already considered this approach, but I avoid regexes as much
as possible. They're great for some work, but they can inadvertently
match too much or fail (for example if the "system" keyword and the
opening brace are on different lines). You see where I'm going? But,
this is a digression...

I also prefer an idempotent approach, and I'm already talking to the
authors of this specific package (knot dns), about making their knot1to2
utility idempotent, so that it's always safe to run it.

However, one problem is that nothing can handle downgrades. The v2
config format is a superset of the v1 format, and while not impossible,
it's very hard to go back. There is no reverse knot2to1 utility.

I'd like to thank everyone for the various suggestions. I'm going to
place with them and see which one works out best.

Finally, as an aside, I'd like to mention that upgrading my own systems
is easy, because I have control over them. My motivation for asking this
question was for making an EPEL package that can work for most people
without breaking their installations (especially if they have unattended
yum updates, like with yum-cron).

Anand

Am 29.06.2015 um 02:11 schrieb Anand Buddhdev <anandb at
ripe.net>:
> On 29/06/15 01:07, Kahlil Hodgson wrote:
> 
>> On 29 June 2015 at 07:37, John R Pierce <pierce at hogranch.com>
wrote:
>> 
>>> so a regex looking for "system:" vs "system {" 
should nicely delineate
>>> these.   I dunno, I might even put that into the conversion utility
and
>>> have it just quit if the file is already in the new format, and
always run
>>> it.
>> 
>> ?+1 for the idempotent approach. IMHO much more robust. Also consider
what
>> will happen if someone does a 'yum downgrade' on the package or
a
>> dependency -- you might want to allow the conversion to go both ways or
at
>> least complain appropriately.
> 
> Yep. I've already considered this approach, but I avoid regexes as much
> as possible. They're great for some work, but they can inadvertently
> match too much or fail (for example if the "system" keyword and
the
> opening brace are on different lines). You see where I'm going? But,
> this is a digression...
that is exactly what regex can do for you. it confirms the "language" 
of the config file, unattached from new lines or space characters. 
Sure, the expression itself is more "complicated" ... (a combination
of tools is also possible eg. tr, awk, sed, grep)

--
LF

On 06/28/2015 05:11 PM, Anand Buddhdev wrote:
> My motivation for asking this
> question was for making an EPEL package that can work for most people
> without breaking their installations (especially if they have unattended
> yum updates, like with yum-cron).
Bear in mind that one of the reasons people use stable distributions 
like RHEL/CentOS is that what you are suggesting does not happen.  Major 
changes should not be made during a platforms support lifetime.

Postgresql is a good example for the best way to handle this.  RHEL 5 
was originally released with Postgresql 8.1.  When 8.4 was released, it 
had features that made it highly desirable, but it wasn't compatible 
with the existing data files.  The new version was released as 
postgresql84 so that admins who wanted it could upgrade manually, but 
the upgrade would not happen automatically.

Maybe the best thing to do is release knotdns2 and avoid surprising 
admins with changes they need to prepare for.