FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 02-24-2010, 05:36 PM
BJ Dierkes
 
Default Incompatible upgrade - Is this workaround ok? (mysql-mmm)

Hello all,

I maintain Multi-Master Replication Manager for MySQL in both Fedora and EPEL. With changes from 2.0.11 -> 2.1.0 there was an incompatible change in that the daemon scripts were renamed:

mmmd_agent -> mmm_agentd
mmmd_mon -> mmm_mond


Upgrades obviously break because the INIT scripts and configuration files reference the path to the files. Would a sufficient work-around be a symlink to the old path, or would that not be kosher for any reason?

Thank you for your feedback.

---
derks



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-24-2010, 05:36 PM
BJ Dierkes
 
Default Incompatible upgrade - Is this workaround ok? (mysql-mmm)

Hello all,

I maintain Multi-Master Replication Manager for MySQL in both Fedora and EPEL. With changes from 2.0.11 -> 2.1.0 there was an incompatible change in that the daemon scripts were renamed:

mmmd_agent -> mmm_agentd
mmmd_mon -> mmm_mond


Upgrades obviously break because the INIT scripts and configuration files reference the path to the files. Would a sufficient work-around be a symlink to the old path, or would that not be kosher for any reason?

Thank you for your feedback.

---
derks




_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 02-25-2010, 02:26 AM
Stephen John Smoogen
 
Default Incompatible upgrade - Is this workaround ok? (mysql-mmm)

On Wed, Feb 24, 2010 at 11:36 AM, BJ Dierkes
<wdierkes@5dollarwhitebox.org> wrote:
> Hello all,
>
> I maintain Multi-Master Replication Manager for MySQL in both Fedora and EPEL. *With changes from 2.0.11 -> 2.1.0 there was an incompatible change in that the daemon scripts were renamed:
>
> mmmd_agent -> mmm_agentd
> mmmd_mon -> mmm_mond
>

I think this will need someone from Fedora packaging to comment versus
EPEL (as that would have precedence.) My un-educated opinion is that
there would not be a problem with symlinks if its for files. [Symlinks
for directories I think causes RPM heartburn somewhere but thats a
vague recollection.]

> Upgrades obviously break because the INIT scripts and configuration files reference the path to the files. *Would a sufficient work-around be a symlink to the old path, or would that not be kosher for any reason?
>
> Thank you for your feedback.
>
> ---
> derks
>
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>



--
Stephen J Smoogen.

Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-25-2010, 02:26 AM
Stephen John Smoogen
 
Default Incompatible upgrade - Is this workaround ok? (mysql-mmm)

On Wed, Feb 24, 2010 at 11:36 AM, BJ Dierkes
<wdierkes@5dollarwhitebox.org> wrote:
> Hello all,
>
> I maintain Multi-Master Replication Manager for MySQL in both Fedora and EPEL. *With changes from 2.0.11 -> 2.1.0 there was an incompatible change in that the daemon scripts were renamed:
>
> mmmd_agent -> mmm_agentd
> mmmd_mon -> mmm_mond
>

I think this will need someone from Fedora packaging to comment versus
EPEL (as that would have precedence.) My un-educated opinion is that
there would not be a problem with symlinks if its for files. [Symlinks
for directories I think causes RPM heartburn somewhere but thats a
vague recollection.]

> Upgrades obviously break because the INIT scripts and configuration files reference the path to the files. *Would a sufficient work-around be a symlink to the old path, or would that not be kosher for any reason?
>
> Thank you for your feedback.
>
> ---
> derks
>
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>



--
Stephen J Smoogen.

Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 02-25-2010, 02:41 AM
"Chen Lei"
 
Default Incompatible upgrade - Is this workaround ok? (mysql-mmm)

It's not problem to update mysql-mmm to the latest version for F13 and devel soon.
For F11 F12 and EPEL5, you need write Scriptlet in the pre and check the startlevel of mmmd_agent and
mmmd_mon, then you can adapt the startlevel mmmd_agent based on mmm_agentd and mmmd_mon based on
mmm_mond. There may be some more hack to do for configuration¬*files.

I think symlink isn't a good idea.

Śú®2010-02-25¬*02:36:31ÔľĆ"BJ¬*Dierkes"¬*<wdierkes@5dollarwhi tebox.org>¬*ŚÜôťĀďÔľö
>Hello¬*all,
>
>I¬*maintain¬*Multi-Master¬*Replication¬*Manager¬*for¬*MySQL¬*in¬*both ¬*Fedora¬*and¬*EPEL.¬*¬*With¬*changes¬*from¬*2.0.1 1¬*->¬*2.1.0¬*there¬*was¬*an¬*incompatible¬*change¬*in ¬*that¬*the¬*daemon¬*scripts¬*were¬*renamed:
>
>mmmd_agent¬*->¬*mmm_agentd
>mmmd_mon¬*->¬*mmm_mond
>
>
>Upgrades¬*obviously¬*break¬*because¬*the¬*INIT¬*s cripts¬*and¬*configuration¬*files¬*reference¬*the¬ *path¬*to¬*the¬*files.¬*¬*Would¬*a¬*sufficient¬*wo rk-around¬*be¬*a¬*symlink¬*to¬*the¬*old¬*path,¬*or¬*w ould¬*that¬*not¬*be¬*kosher¬*for¬*any¬*reason?
>
>Thank¬*you¬*for¬*your¬*feedback.
>
>---
>derks
>
>
>
>--¬*
>devel¬*mailing¬*list
>devel@lists.fedoraproject.org
>https://admin.fedoraproject.org/mailman/listinfo/devel


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-25-2010, 03:47 PM
BJ Dierkes
 
Default Incompatible upgrade - Is this workaround ok? (mysql-mmm)

On Feb 24, 2010, at 9:41 PM, Chen Lei wrote:

> It's not problem to update mysql-mmm to the latest version for F13 and devel soon.
> For F11 F12 and EPEL5, you need write Scriptlet in the pre and check the startlevel of mmmd_agent and
> mmmd_mon, then you can adapt the startlevel mmmd_agent based on mmm_agentd and mmmd_mon based on
> mmm_mond. There may be some more hack to do for configuration files.
>
> I think symlink isn't a good idea.

Thank you. To clarify, mmmd_{agent,mon} are the names of the scripts in /usr/sbin and not the name of the init scripts (mysql-mmm-agent, mysql-mmm-monitor). However, the sbin scripts are referenced inside the init scripts.

I suppose an alternative to creating a symlink in /usr/sbin would be to sed the init/config files to reference the new paths in %post. My issue with that however is that I only want to make such changes if the previously installed version is < 2.1. Is there a fedora proper way of determining the version of a package before the upgrade and only performing upgrade actions in that condition only. Maybe something like:

%pre
# determine current version, > /tmp/somewhere

%post
# read previous version from /tmp/somewhere, if version < 2.1 then sed up init/config files for new paths


Just a thought.. I've done something like this before, but not under Fedora/EPEL.

Additionally, an option would be to rename the new sbin scripts to have the old name... but the old name is not standard, and it would be right to follow upstream where all their documentation references the new paths.

Thanks.

---
derks



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-26-2010, 04:11 PM
Kevin Fenzi
 
Default Incompatible upgrade - Is this workaround ok? (mysql-mmm)

On Wed, 24 Feb 2010 12:36:31 -0600
BJ Dierkes <wdierkes@5dollarwhitebox.org> wrote:

> Hello all,
>
> I maintain Multi-Master Replication Manager for MySQL in both Fedora
> and EPEL. With changes from 2.0.11 -> 2.1.0 there was an
> incompatible change in that the daemon scripts were renamed:
>
> mmmd_agent -> mmm_agentd
> mmmd_mon -> mmm_mond
>
>
> Upgrades obviously break because the INIT scripts and configuration
> files reference the path to the files. Would a sufficient
> work-around be a symlink to the old path, or would that not be kosher
> for any reason?
>
> Thank you for your feedback.

Well, I would suggest if you can get it setup so it continues to work
as expected on upgrade it should be fine. If thats a symlink or
whatever it should be ok.

Perhaps make and test a version, then post the spec diff for
comment/feedback if you like?

kevin
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-26-2010, 04:11 PM
Kevin Fenzi
 
Default Incompatible upgrade - Is this workaround ok? (mysql-mmm)

On Wed, 24 Feb 2010 12:36:31 -0600
BJ Dierkes <wdierkes@5dollarwhitebox.org> wrote:

> Hello all,
>
> I maintain Multi-Master Replication Manager for MySQL in both Fedora
> and EPEL. With changes from 2.0.11 -> 2.1.0 there was an
> incompatible change in that the daemon scripts were renamed:
>
> mmmd_agent -> mmm_agentd
> mmmd_mon -> mmm_mond
>
>
> Upgrades obviously break because the INIT scripts and configuration
> files reference the path to the files. Would a sufficient
> work-around be a symlink to the old path, or would that not be kosher
> for any reason?
>
> Thank you for your feedback.

Well, I would suggest if you can get it setup so it continues to work
as expected on upgrade it should be fine. If thats a symlink or
whatever it should be ok.

Perhaps make and test a version, then post the spec diff for
comment/feedback if you like?

kevin
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 03-01-2010, 10:19 PM
BJ Dierkes
 
Default Incompatible upgrade - Is this workaround ok? (mysql-mmm)

On Feb 26, 2010, at 11:11 AM, Kevin Fenzi wrote:

> On Wed, 24 Feb 2010 12:36:31 -0600
> BJ Dierkes <wdierkes@5dollarwhitebox.org> wrote:
>
>> Hello all,
>>
>> I maintain Multi-Master Replication Manager for MySQL in both Fedora
>> and EPEL. With changes from 2.0.11 -> 2.1.0 there was an
>> incompatible change in that the daemon scripts were renamed:
>>
>> mmmd_agent -> mmm_agentd
>> mmmd_mon -> mmm_mond
>>
>>
>> Upgrades obviously break because the INIT scripts and configuration
>> files reference the path to the files. Would a sufficient
>> work-around be a symlink to the old path, or would that not be kosher
>> for any reason?
>>
>> Thank you for your feedback.
>
> Well, I would suggest if you can get it setup so it continues to work
> as expected on upgrade it should be fine. If thats a symlink or
> whatever it should be ok.
>
> Perhaps make and test a version, then post the spec diff for
> comment/feedback if you like?
>
> kevin


I have a working upgrade from mysql-mmm-2.0.x -> mysql-mmm-2.1. I verified that all expected changes happen, and that the running processes are gracefully condrestart'd.

The changes are pretty straight forward. Because this is the first release of mysql-mmm >= 2.1 I am touching a file at '%{_datadir}/mysql-mmm/.pre-2.1.0-upgrade-check' in the install. From %pre, if this file does *not* exist then the current install is < 2.1 (meaning modifications need to be done for 2.1 compatibility). I then touch '%{_localstatedir}/run/mysql-mmm/.post-2.1.0-upgrade-do_mods' (in %pre) allowing me to verify that modifications are needed in %post.

The modifications are simple sed changes for pid/status file and sbin daemon paths. I suppose I'm looking for another set of eyes to point out anything that is not obvious to me. The following are the [snipped] spec changes:

# --------------------------------------------------
%install
# … snipped
# Specific for upgrading from 2.0.x -> 2.1
touch %{buildroot}%{_datadir}/mysql-mmm/.pre-2.1.0-upgrade-check-do-not-delete


%pre
# This is to facilitate the upgradability of 2.0.x -> 2.1
DO_MOD_CHECK="%{_datadir}/mysql-mmm/.pre-2.1.0-upgrade-check-do-not-delete"
DO_MOD_VERIFY="%{_localstatedir}/run/mysql-mmm/.post-2.1.0-upgrade-do_mods"

rm -f $DO_MOD_VERIFY 2>/dev/null

if [ ! -f "$DO_MOD_CHECK" ]; then
# the 'check' file does *not* exist (only installed as of 2.1.0)
# modifications are necessary.
touch $DO_MOD_VERIFY

# copy paths for new configs (if replaced on upgrade)
cp -a %{_localstatedir}/run/mysql-mmm/mmmd_mon.pid
%{_localstatedir}/run/mysql-mmm/mmm_mond.pid 2>/dev/null ||:
cp -a %{_localstatedir}/lib/mysql-mmm/mmmd_mon.status
%{_localstatedir}/lib/mysql-mmm/mmm_mond.status 2>/dev/null ||:
cp -a %{_localstatedir}/run/mysql-mmm/mmmd_agent.pid
%{_localstatedir}/run/mysql-mmm/mmm_agentd.pid 2>/dev/null ||:
fi


%post
# This is to facilitate the upgradability of 2.0.x -> 2.1
DO_MOD_VERIFY="%{_localstatedir}/run/mysql-mmm/.post-2.1.0-upgrade-do_mods"

if [ -f "$DO_MOD_VERIFY" ]; then
# system was upgraded from < 2.1, need to modify config files/paths
if [ -f %{_sysconfdir}/mysql-mmm/mmm_mon.conf ]; then
cp -a %{_sysconfdir}/mysql-mmm/mmm_mon.conf %{_sysconfdir}/mysql-mmm/mmm_mon.conf-pre2.1
sed -i "s|/var/run/mysql-mmm/mmmd_mon.pid|/var/run/mysql-mmm/mmm_mond.pid|g"
%{_sysconfdir}/mysql-mmm/mmm_mon.conf
sed -i "s|/var/lib/mysql-mmm/mmmd_mon.status|/var/lib/mysql-mmm/mmm_mond.status|g"
%{_sysconfdir}/mysql-mmm/mmm_mon.conf
fi
if [ -f %{_sysconfdir}/mysql-mmm/mmm_common.conf ]; then
cp -a %{_sysconfdir}/mysql-mmm/mmm_common.conf %{_sysconfdir}/mysql-mmm/mmm_common.conf-pre2.1
sed -i "s|/var/run/mysql-mmm/mmmd_agent.pid|/var/run/mysql-mmm/mmm_agentd.pid|g"
%{_sysconfdir}/mysql-mmm/mmm_common.conf
fi
fi


%post agent
# … snipped
# This is to facilitate the upgradability of 2.0.x -> 2.1
DO_MOD_VERIFY="%{_localstatedir}/run/mysql-mmm/.post-2.1.0-upgrade-do_mods"
if [ -f "$DO_MOD_VERIFY" ]; then
# remove old files
rm -f %{_localstatedir}/run/mysql-mmm/mmmd_agent.pid 2>/dev/null ||:
fi


%post monitor
# … snipped
# This is to facilitate the upgradability of 2.0.x -> 2.1
DO_MOD_VERIFY="%{_localstatedir}/run/mysql-mmm/.post-2.1.0-upgrade-do_mods"
if [ -f "$DO_MOD_VERIFY" ]; then
# remove old files
rm -f %{_localstatedir}/run/mysql-mmm/mmmd_mon.pid 2>/dev/null ||:
rm -f %{_localstatedir}/lib/mysql-mmm/mmmd_mon.status 2>/dev/null ||:
fi
# --------------------------------------------------


Thanks.

---
derks

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-01-2010, 10:19 PM
BJ Dierkes
 
Default Incompatible upgrade - Is this workaround ok? (mysql-mmm)

On Feb 26, 2010, at 11:11 AM, Kevin Fenzi wrote:

> On Wed, 24 Feb 2010 12:36:31 -0600
> BJ Dierkes <wdierkes@5dollarwhitebox.org> wrote:
>
>> Hello all,
>>
>> I maintain Multi-Master Replication Manager for MySQL in both Fedora
>> and EPEL. With changes from 2.0.11 -> 2.1.0 there was an
>> incompatible change in that the daemon scripts were renamed:
>>
>> mmmd_agent -> mmm_agentd
>> mmmd_mon -> mmm_mond
>>
>>
>> Upgrades obviously break because the INIT scripts and configuration
>> files reference the path to the files. Would a sufficient
>> work-around be a symlink to the old path, or would that not be kosher
>> for any reason?
>>
>> Thank you for your feedback.
>
> Well, I would suggest if you can get it setup so it continues to work
> as expected on upgrade it should be fine. If thats a symlink or
> whatever it should be ok.
>
> Perhaps make and test a version, then post the spec diff for
> comment/feedback if you like?
>
> kevin


I have a working upgrade from mysql-mmm-2.0.x -> mysql-mmm-2.1. I verified that all expected changes happen, and that the running processes are gracefully condrestart'd.

The changes are pretty straight forward. Because this is the first release of mysql-mmm >= 2.1 I am touching a file at '%{_datadir}/mysql-mmm/.pre-2.1.0-upgrade-check' in the install. From %pre, if this file does *not* exist then the current install is < 2.1 (meaning modifications need to be done for 2.1 compatibility). I then touch '%{_localstatedir}/run/mysql-mmm/.post-2.1.0-upgrade-do_mods' (in %pre) allowing me to verify that modifications are needed in %post.

The modifications are simple sed changes for pid/status file and sbin daemon paths. I suppose I'm looking for another set of eyes to point out anything that is not obvious to me. The following are the [snipped] spec changes:

# --------------------------------------------------
%install
# … snipped
# Specific for upgrading from 2.0.x -> 2.1
touch %{buildroot}%{_datadir}/mysql-mmm/.pre-2.1.0-upgrade-check-do-not-delete


%pre
# This is to facilitate the upgradability of 2.0.x -> 2.1
DO_MOD_CHECK="%{_datadir}/mysql-mmm/.pre-2.1.0-upgrade-check-do-not-delete"
DO_MOD_VERIFY="%{_localstatedir}/run/mysql-mmm/.post-2.1.0-upgrade-do_mods"

rm -f $DO_MOD_VERIFY 2>/dev/null

if [ ! -f "$DO_MOD_CHECK" ]; then
# the 'check' file does *not* exist (only installed as of 2.1.0)
# modifications are necessary.
touch $DO_MOD_VERIFY

# copy paths for new configs (if replaced on upgrade)
cp -a %{_localstatedir}/run/mysql-mmm/mmmd_mon.pid
%{_localstatedir}/run/mysql-mmm/mmm_mond.pid 2>/dev/null ||:
cp -a %{_localstatedir}/lib/mysql-mmm/mmmd_mon.status
%{_localstatedir}/lib/mysql-mmm/mmm_mond.status 2>/dev/null ||:
cp -a %{_localstatedir}/run/mysql-mmm/mmmd_agent.pid
%{_localstatedir}/run/mysql-mmm/mmm_agentd.pid 2>/dev/null ||:
fi


%post
# This is to facilitate the upgradability of 2.0.x -> 2.1
DO_MOD_VERIFY="%{_localstatedir}/run/mysql-mmm/.post-2.1.0-upgrade-do_mods"

if [ -f "$DO_MOD_VERIFY" ]; then
# system was upgraded from < 2.1, need to modify config files/paths
if [ -f %{_sysconfdir}/mysql-mmm/mmm_mon.conf ]; then
cp -a %{_sysconfdir}/mysql-mmm/mmm_mon.conf %{_sysconfdir}/mysql-mmm/mmm_mon.conf-pre2.1
sed -i "s|/var/run/mysql-mmm/mmmd_mon.pid|/var/run/mysql-mmm/mmm_mond.pid|g"
%{_sysconfdir}/mysql-mmm/mmm_mon.conf
sed -i "s|/var/lib/mysql-mmm/mmmd_mon.status|/var/lib/mysql-mmm/mmm_mond.status|g"
%{_sysconfdir}/mysql-mmm/mmm_mon.conf
fi
if [ -f %{_sysconfdir}/mysql-mmm/mmm_common.conf ]; then
cp -a %{_sysconfdir}/mysql-mmm/mmm_common.conf %{_sysconfdir}/mysql-mmm/mmm_common.conf-pre2.1
sed -i "s|/var/run/mysql-mmm/mmmd_agent.pid|/var/run/mysql-mmm/mmm_agentd.pid|g"
%{_sysconfdir}/mysql-mmm/mmm_common.conf
fi
fi


%post agent
# … snipped
# This is to facilitate the upgradability of 2.0.x -> 2.1
DO_MOD_VERIFY="%{_localstatedir}/run/mysql-mmm/.post-2.1.0-upgrade-do_mods"
if [ -f "$DO_MOD_VERIFY" ]; then
# remove old files
rm -f %{_localstatedir}/run/mysql-mmm/mmmd_agent.pid 2>/dev/null ||:
fi


%post monitor
# … snipped
# This is to facilitate the upgradability of 2.0.x -> 2.1
DO_MOD_VERIFY="%{_localstatedir}/run/mysql-mmm/.post-2.1.0-upgrade-do_mods"
if [ -f "$DO_MOD_VERIFY" ]; then
# remove old files
rm -f %{_localstatedir}/run/mysql-mmm/mmmd_mon.pid 2>/dev/null ||:
rm -f %{_localstatedir}/lib/mysql-mmm/mmmd_mon.status 2>/dev/null ||:
fi
# --------------------------------------------------


Thanks.

---
derks


_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 

Thread Tools




All times are GMT. The time now is 11:53 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org