Orphaned Packages
Hello all, I was previously involved with the Drizzle community, however due to changes in my current role at my $dayjob I am no longer much involved with the project. The following packages were maintained as part of that project, and therefore I am orphaning them. Some may need to be deprecated (or obsoleted), but I am giving the option for others to pick these up easily being that they will be auto-deprecated before next release. FEDORA: - haildb - libdrizzle - python-drizzle EPEL: - haildb - libdrizzle - python-drizzle - protobuf --- derks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Removing SysV Init Scripts
Sorry, I didn't mean to start a heated thread on SysV vs. Systemd or anything. Unfortunately my question wasn't really answered. I *am* removing SysV support from gearmand … and have already implemented Systemd scripts. My question is… for existing users still on SysV in Fedora < 17 …. are there any safeguards I need to put in place as to not break them… or should I just rip out all the SysV stuff and hope for the best? Thanks. --- derks On Jan 13, 2012, at 3:31 PM, BJ Dierkes wrote: > Hello, > > I have this bug open: > > https://bugzilla.redhat.com/show_bug.cgi?id=781451 > > > And so, I am needing to remove my sysvinit scripts from gourmand in rawhide. > I've read the docs on SysVInit Scripts and Systemd but haven't found an > answer… How should I handle removing the init script? Should I just assume > that users are moved over to systemd? Do I need to call 'chkconfig --del > gearmand'? > > --- > 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
Removing SysV Init Scripts
Hello, I have this bug open: https://bugzilla.redhat.com/show_bug.cgi?id=781451 And so, I am needing to remove my sysvinit scripts from gourmand in rawhide. I've read the docs on SysVInit Scripts and Systemd but haven't found an answer… How should I handle removing the init script? Should I just assume that users are moved over to systemd? Do I need to call 'chkconfig --del gearmand'? --- derks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Heads up: protobuf .so version bump in Rawhide
Hello all, I've pushed the latest protobuf-2.4.1 to Rawhide, which bumps libprotobuf.so.6 to libprotobuf.so.7. This appears to affect the following "base" packages: * libcompizconfig * mozc * mumble * protobuf-c The primary maintainers of the above have been BCC'd. Thanks. --- derks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
GitHub Hosted upstream 'Source0'
Hello all, I hope I am not the first to come across packaging issues for projects that use GitHub as their upstream source download. For those not familiar, GitHub dynamically generates downloads for all git 'tags'. So for example: $ git tag -a -m 'Tagging 1.0.0' 1.0.0 This would create a tag of '1.0.0' in git. On GitHub, this tag would be 'downloadable' via a dynamic app such as: https://github.com/derks/myapp/zipball/1.0.0 This is the upstream URL that a lot of GitHub users are providing rather than a direct download link. Unfortunately the above is not usable by RPM because rpmbuild expects the URL to end with the file. If I were to use the above in my spec, I would get an error saying something to the affect of 'unknown source file 1.0.0'. Additionally, the tarbal that is created looks like: myapp-1.0.0-XXX.tar.gz Where XXX is the last bit of the git commit hash id... which cause yet another pain in that... you need to update this commit revision every time you update the spec... and it just makes things a bit less fluid. I'm wondering how other people have resolved these issues for projects using GitHub as the upstream Source0 download provider. Finally, debian has a web app to resolve these issues at: http://githubredir.debian.net/ What would be the thoughts of using that to produce more sane/traditional tarbals of upstream GitHub source? --- derks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anyone packaging python-cloudfiles?
I've taken over that review, and will post an updated spec/srpm shortly. --- derks On Jan 17, 2011, at 5:12 PM, Rahul Sundaram wrote: > Hi > > I only see a old review request at > https://bugzilla.redhat.com/show_bug.cgi?id=542436 and the spec file is not > available anymore. The latest development version of Deja-dup (default > backup software in GNOME using duplicity) requires it to backup to S3 or > Rackspace clouds. If anyone is packaging it, I can help review it. Let me > know > > Rahul > -- > 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
Re: Requesting a new scm module for a new package
Adam, First, thank you for joining as a Fedora contributor. You need to complete the following before submitting for SCM module: Find a sponsor. As this is your first package, you must have a 'proven packager' sponsor you. See [1] The sponsor must complete a formal review of your package. Anyone can add comments to your review, and do an 'unofficial review' to help you along. However the review is not formally complete until your sponsor says so, and adds the 'fedora-review +' flag. Currently the review has not even started, otherwise the 'fedora-review' flag would be set as '?' (once a sponsor picks up your review). References: [1] http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group --- derks On Jan 6, 2011, at 1:19 PM, Adam Litke wrote: > Hello all. I am a new Fedora packager and am following the process to > create a new package. The associated bugzilla is 638647 [1]. At this > point I am trying to request a new SCM module for my package and have > followed the documented steps [2] but nothing has happened in 24 hours. > Is this an automated process or does it require human intervention. > Does anyone know if there is a specific problem with the state of my > bugzilla bug that might be preventing the request from being picked > up? > > Thanks for your help! > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=638647 > [2] http://fedoraproject.org/wiki/Package_SCM_admin_requests > -- > Thanks, > Adam > > -- > 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
Re: Python Packages + Multiple Sources
On Dec 8, 2010, at 1:53 PM, Jeff Spaleta wrote: > On Wed, Dec 8, 2010 at 6:06 PM, BJ Dierkes > wrote: >> That is exactly right. > > reading over the instructions on the pypi page for cement.devtools > explicitly tells people to easy_install cement prior to > easy_install'ing cement.devtools, so I wanted clarification as to > whether that was necessasry. > I've updated this to be more accurate, thank you. --- derks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Python Packages + Multiple Sources
On Dec 8, 2010, at 2:55 AM, Stanislav Ochotnicky wrote: > On 12/08/2010 04:25 AM, Jeff Spaleta wrote: >> On Wed, Dec 8, 2010 at 2:39 AM, BJ Dierkes >> wrote: >>> Hello all, >>> >> >> Just to be clear... PyPI has an implied "one source" requirement >> embedded in its repository structure and you have optimized your >> upstream project release structure to meet PyPI's implied requirement. >> >> Question does PyPI handle dependency tracking? >> >> If I easy_install cement.devtools does cement get installed automagically? > > Yes, setup function from python setuptools has named argument > 'install_requires' that causes dependencies to be pulled in during > install time. Assuming cement.devtools has install_requires = ['cement'] > this will work as you'd expect > That is exactly right. --- derks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Python Packages + Multiple Sources
Hello all, I've been trying to figure the best way to handle this situation for the better part of two days... and so I figured I'd bring it on list and hopefully I can clarify this all. I have several projects that relate to this question, however I will reference 'cement' as an example. Basically, cement is a CLI Application Framework for Python [1]. I am also the upstream maintainer, so I have the ability to modify upstream or downstream. Currently, cement consists of three separate sources: cement cement.devtools cement.test All three pieces follow each release meaning, when 0.8.12 (current stable) was released... new tarbals were released for all three. The reason for separate tarbals is primarily for maintaining releases via PyPi [2]. I need all three pieces to be separate so that users can 'easy_install cement', without pulling in a dozen dependencies for cement.devtools or cement.test. I don't have the luxury of creating 'subpackages' in PyPi, so I have to break up the sources. That said, in the Fedora world... it is a bit excessive to maintain three separate RPM packages (for all Fedora/EPEL releases)... when all three packages are related and could easily role up under a single package, with subpackages. I have the same issue with 'rosendale' [3] which is/will be a set of plugins for applications built on cement. The same situation exists, in PyPi I need separate source tarbals because users need to be able to 'easy_install rosendale.some_plugin'. In Fedora world, maintaining a single package set for 'rosendale' would be ideal and make more sense because I can do sub packages for each plugin and not have to maintain 20 different package sets. What I would like to see is if this type of situation would lend itself to making an exception to the FPG regarding 'one source per package'. I assume the section 'Bundling of multiple projects' [4] is relevant, though it is pretty vague. I guess what I'm looking for is for someone with more time in the community to give some advice on this situation. Ideally, I would like to be able to maintain a single package set for say 'cement', but with Source0 (cement), Source1 (cement.devtools), Source2 (cement.test). Or would it be recommended to have a separate tarbal like 'cement-all-0.8.12.tar.gz' which would include all parts of the project, and use that as Source0? Thanks for your time. References: [1] http://builtoncement.org [2] http://pypi.python.org [3]http://builtoncement.org/rosendale/1.0/doc/ [4] http://fedoraproject.org/wiki/PackagingGuidelines#Bundling_of_multiple_projects --- derks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: php-pear dependencies install httpd
php-pear most likely depends on php-devel as a courtesy, based on the fact that PECL requires php-devel in order to build some/most/all (?) of its modules. Meaning, when someone says: # pecl install foo Foo requires php-devel to build properly, and install the module. Without php-devel as a dependency of php-pear, users would be confronted to sometimes obscure pecl install failures. --- derks On Dec 1, 2010, at 6:45 AM, Martín Marqués wrote: > I have my laptop with php-cli and php-pear installed, and I was to do > an upgrade and found that yum wanted to install httpd package to my > surprise. > > Looking in detail, I found that php-pear needed php-devel, which needs > php, which needs httpd. > > --> Ejecutando prueba de transacción > ---> Paquete php-pear.noarch 1:1.9.1-5.fc13 definido para ser actualizado > --> Procesando dependencias: php-devel para el paquete: > 1:php-pear-1.9.1-5.fc13.noarch > --> Ejecutando prueba de transacción > ---> Paquete php-devel.x86_64 0:5.3.3-1.fc13 definido para ser instalado > --> Procesando dependencias: php = 5.3.3-1.fc13 para el paquete: > php-devel-5.3.3-1.fc13.x86_64 > --> Ejecutando prueba de transacción > ---> Paquete php.x86_64 0:5.3.3-1.fc13 definido para ser instalado > --> Procesando dependencias: httpd-mmn = 20051115 para el paquete: > php-5.3.3-1.fc13.x86_64 > --> Procesando dependencias: httpd para el paquete: php-5.3.3-1.fc13.x86_64 > --> Ejecutando prueba de transacción > ---> Paquete httpd.x86_64 0:2.2.17-1.fc13.1 definido para ser instalado > --> Procesando dependencias: httpd-tools = 2.2.17-1.fc13.1 para el > paquete: httpd-2.2.17-1.fc13.1.x86_64 > --> Procesando dependencias: apr-util-ldap para el paquete: > httpd-2.2.17-1.fc13.1.x86_64 > --> Ejecutando prueba de transacción > ---> Paquete apr-util-ldap.x86_64 0:1.3.10-1.fc13 definido para ser instalado > ---> Paquete httpd-tools.x86_64 0:2.2.17-1.fc13.1 definido para ser instalado > > Any ideas why these dependencies appeared? Basically, whi does > php-pear need php-devel. > > -- > Martín Marqués > select 'martin.marques' || '@' || 'gmail.com' > DBA, Programador, Administrador > -- > 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
Re: Issues with bodhi (No JSON object could be decoded)
Sorry, just saw your reply
On May 14, 2010, at 2:41 AM, Luke Macken wrote:
>
> I'm seeing your POST requests in the logs, but some of them are not
> hitting bodhi's save() method, which means it's not getting past the
> identity layer. Does it work after you `rm ~/.fedora/.fedora_session`?
> Also, does passing -v to bodhi show anything useful?
>
Removing the session doesn't work.
$ bodhi -n --type bug mysql-mmm-2.2.1-1.fc12 --username derks -v
proxyclient.__init__:entered
proxyclient.__init__:exited
Creating a new update for mysql-mmm-2.2.1-1.fc12
No session cached for "derks"
No session cached for "derks"
Password for derks:
Creating a new update for mysql-mmm-2.2.1-1.fc12
No session cached for "derks"
proxyclient.send_request: entered
Creating request https://admin.fedoraproject.org/updates/save
Headers: ['User-agent: Fedora Bodhi Client/0.5.1', 'Accept: application/json']
Data:
close_bugs=True&edited=&suggest_reboot=False&unstable_karma=-3&password=xxx&stable_karma=3&builds=mysql-mmm-2.2.1-1.fc12&autokarma=True&inheritance=False¬es=&request=testing&bugs=&type_=bug&login=Login&user_name=derks
ServerError(https://admin.fedoraproject.org/updates/save, 200, Error returned
from simplejson while processing https://admin.fedoraproject.org/updates/save:
No JSON object could be decoded)
Traceback (most recent call last):
File "/usr/bin/bodhi", line 178, in main
data = bodhi.save(**extra_args)
File "/usr/lib/python2.6/site-packages/fedora/client/bodhi.py", line 111, in
save
'bugs': bugs,
File "/usr/lib/python2.6/site-packages/fedora/client/baseclient.py", line
316, in send_request
req_params = req_params, auth_params = auth_params)
File "/usr/lib/python2.6/site-packages/fedora/client/proxyclient.py", line
313, in send_request
{'url': url, 'err': str(e)})
ServerError: ServerError(https://admin.fedoraproject.org/updates/save, 200,
Error returned from simplejson while processing
https://admin.fedoraproject.org/updates/save: No JSON object could be decoded)
I added a print statement to
/usr/lib/python2.6/site-packages/fedora/client/proxyclient.py and got back HTML
which looks to be the web version of the new update page as the title is:
New Update Form
---
derks
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Issues with bodhi (No JSON object could be decoded)
Hello all,
Is anyone else experiencing these issues?
$ bodhi -n --type bug mysql-mmm-2.2.1-1.fc12 --username derks
Creating a new update for mysql-mmm-2.2.1-1.fc12
ServerError(https://admin.fedoraproject.org/updates/save, 200, Error returned
from simplejson while processing https://admin.fedoraproject.org/updates/save:
No JSON object could be decoded)
Traceback (most recent call last):
File "/usr/bin/bodhi", line 178, in main
data = bodhi.save(**extra_args)
File "/usr/lib/python2.6/site-packages/fedora/client/bodhi.py", line 111, in
save
'bugs': bugs,
File "/usr/lib/python2.6/site-packages/fedora/client/baseclient.py", line
316, in send_request
req_params = req_params, auth_params = auth_params)
File "/usr/lib/python2.6/site-packages/fedora/client/proxyclient.py", line
313, in send_request
{'url': url, 'err': str(e)})
ServerError: ServerError(https://admin.fedoraproject.org/updates/save, 200,
Error returned from simplejson while processing
https://admin.fedoraproject.org/updates/save: No JSON object could be decoded)
I just did a successful push for EL5, now this. I had these issues 2 days ago
with el5,fc12,fc13... which was the last time I tried. Am I missing something?
Seems I'm getting a 200 response, but the update doesn't show up in admin
updates at all.
Using: bodhi-client-0.7.4-1.fc12
---
derks
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Review Swap: Your two for my libdrizzle/python-drizzle
Hello all, I've got two reviews that have been around for a bit... looking to do a review or two in return for having someone review these: libdrizzle: https://bugzilla.redhat.com/show_bug.cgi?id=578981 python-drizzle: https://bugzilla.redhat.com/show_bug.cgi?id=581344 Please note that I can't sponsor. --- derks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Packages where upstream sources are alpha/beta
Hello, I am working with the Drizzle project [1], and have been focussing mostly on packaging. I am beginning to submit review requests for libdrizzle, python-drizzle, etc... the supporting pieces that are mature. However drizzle itself is still under heavy development and is considered alpha/almost beta. I've read the guidelines on versions [2] which mentions alpha/beta/cvs releases but doesn't really go into any detail. In short, my question is if there are any restrictions around submitting packages that are pre-release and if so can you provide any information that is available. [1] http://drizzle.org, http://launchpad.net/drizzle [2] https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Package_Version Thanks. p.s. If anyone wants to review libdrizzle, it's still waiting: https://bugzilla.redhat.com/show_bug.cgi?id=578981 --- derks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Managing spec files
On Mar 8, 2010, at 10:59 AM, Steve Traylen wrote: >> > It is true that the separate .spec files are maintained separately. What many > people try and do is maintain them as identical, at least at the start. > Have a look at: > http://fedoraproject.org/wiki/Packaging/DistTag#Conditionals > of course with time with different update policies it will happen that say > EPEL > and rawhide .specs diverge. > Maintaining a single spec with disttag conditionals is great, and makes the world a lot easier *if* you are maintaining the same source version of the package across all distros. Once you split source versions (as Steve said generally with rawhide)... its not really practical to maintain a single spec and you end up with multiple buildroots/specs. --- derks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 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 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
Re: 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
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
