See http://www.bacula.org/en/rel-manual/Bacula_RPM_Packaging_FAQ.html and trunk/bacula/platforms/contrib-rpm directory
But the answer to your question, I did not find it. I think (perhaps wrongly) that the way may be next. Download bacula-2.4.3-1.src.rpm and install. Download patch 2.4.3-cancel-after-network-outage.patch and manually apply it. Or copy the patch to SOURCES directory and modify bacula.spec: ... Source5: bacula-2.2.7-postgresql.patch Patch1: 2.4.3-cancel-after-network-outage.patch % changelog * Sun Oct 26 2008 Y. Timofeev <[EMAIL PROTECTED]> - Add 2.4.3-cancel-after-network-outage.patch ... and rpmbuild-bb bacula.spec 2008/10/26 Timo Neuvonen <[EMAIL PROTECTED]>: > "Kern Sibbald" <[EMAIL PROTECTED]> kirjoitti viestissä > news:[EMAIL PROTECTED] >> On Saturday 25 October 2008 21:53:00 Ulrich Leodolter wrote: >>> On Sat, 2008-10-25 at 21:11 +0200, Eric Bollengier wrote: >>> > Le Saturday 25 October 2008 13:41:15 Ulrich Leodolter, vous avez écrit >>> > : >>> > > On Sat, 2008-10-25 at 11:32 +0200, Kern Sibbald wrote: >>> > > > Hello, >>> > > > >>> > > > For some time now, I haven't really been happy with the Bacula >>> > > > patch >>> > > > procedure. Basically, when we fix a bug (either from a bug report >>> > > > or >>> > > > ourselves), we usually generate a patch, post it to the bug report, >>> > > > if any, and upload it to the Bacula patches area of Source Forge. >>> > > > >>> > > > Providing you are subscribed to the bugs database and to the >>> > > > bacula-patches release notification on Source Forge, you will see >>> > > > these patches and can apply them if you deem necessary. >>> > > > >>> > > > The problems I have with this is that some people may not know >>> > > > about >>> > > > patches (we see this in bug reports where a problem is already >>> > > > resolved with a patch), and there is no formal mechanism for >>> > > > developers when generating a patch. >>> > > > >>> > > > We already have more work than we can handle, so any change needs >>> > > > to >>> > > > be simple and not time consuming for developers, but I am wondering >>> > > > if anyone has suggestions how to improve this. I can think of a >>> > > > few: >>> > > > >>> > > > 1. Change nothing (signing up for bugs and patch notification is >>> > > > already not bad). >>> > > > 2. Announce patches to the bacula-devel list >>> > > > 3. Announce patches to the bacula-devel list and the bacula-users >>> > > > list 4. Announce patches to the bacula-announce list as well as the >>> > > > other two lists. >>> > > > 5. Put patches in the news (time consuming and I doubt that many >>> > > > read >>> > > > news). 6. Create an rss feed (I doubt that many users use rss, and >>> > > > this also could be time consuming). >>> > > >>> > > Hello, >>> > > >>> > > One thing i am missing are patched packages, rpm and also deb >>> > > packages >>> > > have a mechanism to include patch files an apply during build >>> > > process. >>> > > >>> > > For most bacula users it would be much easier to apply patches by >>> > > "rpm >>> > > -U ..." or "dpkg install ...". >>> > >>> > Yes, but you have to build, test and release a package for each disto >>> > after each patch, this is a *huge* amount of work, we have something >>> > like >>> > 10 patches between two releases. >>> > >>> > If someone want to build, test and package 10 more often than before >>> > for >>> > free, no problem, but i prefere spend my time with new features and >>> > bugs >>> > hunting. >>> > >>> > > Operating systems like RedHat, CentOS, SLES, Debian, ... are always >>> > > at >>> > > least one step behind last official version. >>> > > >>> > > An official bacula package repository (yum, apt) would be great. >>> > >>> > Fedora, debian and ubuntu already provide this kind of repositor, and >>> > often, they have a backport branch. >> >> I was out yesterday, so will answer here in your second email. >> >> Yes, I think having full packages available is the best way to get >> "patches". >> We already sometimes do that. However, as Eric pointed out, it is a lot >> of >> work. The packaging is done by the community. I release a new source tar >> file and (with the exception of Win32), the community creates new packages >> if >> they want. They always do so for new releases, and for what I designate >> as >> critical fixes, but possibly not for all the more minor patches. >> > > I guess there are a number of users who are not familiar with the packaging > process, partially that includes me, although I'm rather used to build many > binaries from source rpms. > > One reasonable way to reduce the burden to the packagers might be, if they > mostly concentrated (now I'm talking only about rpm packages, I don't know > eg. debian) in building the source packages that could be expected to > succesfully build into binaries. I understand that there is a lot of work > after building the source package that somehow seriously can be expected to > work, since the various final binaries preferably should also be installed > in the target systems and tested there -at least to the point they start > nicely. But when it's about "small" minor patches, it might be reasonable > that an experienced packager views the patch and the spec file, and if it > were expected that all this could result in a working binary package, > building the binaries could be left to the end users -at least when it comes > to the very minor patches. > > Currently, at least I am a little bit scared about the idea of building and > installing into a "production environment" an application that was shipped > as a source tarball, since it may conflict with the existing system, and I > have some bad experiencies from the past how to uninstall some tarball > installations (not speaking of Bacula now), though a bad rpm binary may be > hard to uninstall as well. > > So, could a reasonable middle-way be releasing more source rpms, and include > in the release notes an example how to build the binary rpm? Or, if a > supposed-to-be-perfect spec file that can handle the patches is already > included in the tarball, just include an example command sequence how to > build a binary rpm all the way from the source tarball? This would reduce > some raw shovel-level work from the packagers. Then, if the binary could not > be built eg. due to some bug in the spec file, it would be up to the > official packager again if he/she has resources to fix it at that point, or > decides to wait until the next release. > > -- > TiN > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Bacula-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/bacula-devel > -- with best regards ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
