After some discussion in IRC (Fedora-admin) we are wondering if
pushing a new git in EPEL is a good idea. There are some changes such
as git-command vs git command. So there could be some breakage.
Should we push a new git and cause some breakage or stick with old-n-busted?
My thoughts are to push out a new one, since I think if you are using
git, you curse everytime you touch this old crusty thing :)
== summary ==
The current bacula package in EPEL is faulty. I built an upgrade hack so that
we don't require manual intervention by sysadmins. In order to get it right
this time, an rigorous review is desirable.
== background ==
The bacula package (storage+director) in EPEL5 which is shipped since
September 2007 contains a nasty bug in the %post/%postun scriptlets. If the
package is ever updated, a symlink will be missing and bacula will not start
anymore. This can be fixed e.g. by a manual install/uninstall of the bacula
This error was present in Fedora but was fixed there a long time ago.
== current situation ==
We can not update the bacula package (e.g. for security reasons) without
breaking a lot of installs.
== plan for attack ==
The old package will remove the symlink generated by alternatives during
%postun unconditionally (also during upgrade). Therefore we replace the
symlink in the new package with a copy of the real file, alternatives won't
touch it and the user is happy.
After some time when everyone ("almost everyone") upgraded, we ship another
update which reverts this ugly hack.
== current implementation ==
I have a series of spec file patches which implement the fix:
Also I built some test scripts which check some install/uninstall/upgrade
procedures. I wrote at least some lines how to use them in 'how_to_test.txt'.
== roadmap ==
I would like to gather as many reviews as possible on that issue:
- Is this issue worth tackling?
- Is my plan of action sane?
- Any other issues?
1) Wait for reviews+suggestions (1-2 weeks)
2) Commit/build (assuming that the plan is approved)
3) Push a new bacula to testing (2 months)
4) Push bacula to stable
5) Revert upgrade hack
[ ] done
My group is looking at bringing our project into EPEL. Among the
reasons for doing so is to provide our users with ABI stability. The
project is a web service application that is built from a C++ coded
back-end that is driven by user requests through a java servlet. The
way that C and C++ projects are brought into fedora and along into
EPEL seems pretty clearly documented, as are the ABI stability
benefits that are part of EPEL design goals.
However I am seeing almost no discussion about the java side of the
Can you point me to any specific documents or guidelines that would
help me get educated on what the issues are with bringing a java
project into EPEL? IS there any discussion of ABI stability with
regards to Java? Or is API stability the only real issue for java?
I did find this page:
Where I learned that EPEL projects must follow the Fedora Packaging
and Maintenance Guidelines, and which led me to this:
Which led me to this:
Where the details of including an ant project are discussed. However
my core questions about ABI vs API stability vis-a-vis EPEL remain
Additionally, the page on packaging java provides examples of
"Specfile Templates". Is there also a resource to which you may direct
me where I can learn about the format and role of the Specfiles in the
Any help you could offer me in this regard would be most appreciated.
= = =
Nathan Potter ndp at opendap.org
OPeNDAP, Inc. +1.541.231.3317
Back again to the discussion about EPEL packages that override their
RHEL5 contains kvm-qemu-img-83-105.el5_4.22 that provides
qemu-img = 0.9.1.kvm.83
EPEL however provides qemu-img-0.10.5-1.el5.2 so after installing e.g.
python-virtinst from RHEL which requires qemu-img, the user will end up
with qemu-img from EPEL and not kvm-qemu-img.
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.
We have installed rkhunter (V1.3.6-2) from EPEL on our RHEL 5.4
machines and it appears that it does not remove the /dev/shm/suspscan.*
files it uses for the SUSPSCAN test, thus triggering a warning for said
test. AFAIK, this was a known bug that was supposed to be have been
fixed in V1.3.1.
Camron W. Fox
High Performance Computing Group
Fujitsu Management Services of America, Inc.
for a few days I have given permission to perform buildroot overrides.
There was now a request for a buildroot override in all branches
including EPEL. Therefore I wonder whether I should do these, too, or
just ask to create a new ticket for EPEL?
Downloaded client and server x86_64 DVD's for 5.4 and 5.5beta. Got a
list of package names and made a difference list. I am downloading the
src dvd's to do a better 'blocking' list but at the moment here is a
list of changes between 5.4 and 5.5beta
Items removed from 5.5beta that were in 5.4:
Items added from 5.5beta that were NOT in 5.4
Now for the ODD things.. some stuff were moved from RHEL 5.4 client to
and vice versa...
Hope this helps people.
Stephen J Smoogen.
Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning