Yum on Fedora Core (release 6) only seems to find bzr-0.15 and I could not find updated versions of the RPM with a quick google search. I choose to download the bzr-0.15.fc6.src.rpm files and update to bzr 0.90 ... for the good of others I have attached a copy of the resulting SPEC files to this post. RPM is not my specialty but I use Fedora at work. I know that bzr.spec still needs a little help to handle the debug files that rpm 'unpackaged_file_*' macro does not like.
Created attachment 207621 [details] First cut at bzr 0.90 SPEC file
Hi Michael, I've been hesitating to update FC6 because there are some radical changes between bzr-0.16 and bzr-0.91. Namely, some of the code has been rewritten in Pyrex and thus compiles to an arch specific module. For the three packages in Fedora, I'm able to update them all at once so they move from arch independent directories to arch specific directories together but external modules that people have compiled locally and placed in /usr/lib/python2.4/site-packages/bzrlib/plugins/ would break on x86_64 machines. As a bzr user, what do you think is going to cause bzr users the least pain? Working with a slightly out-of-date version of bzr or having the upgrade break unpackaged plugins in this way? Note: I have 0.91 packaged in devel and could push the changes to both F-7 and FC-6. It's just, as I say, a question of whether out-of-datedness or possible breakage takes precedent here.
One other point to note: I'm planning on updating F-7 to 0.91 because it fixes some problems with branching from repositories with tags that are present in 0.18. So this is just a question of whether to update FC-6 or not.
Thank you for the quick response time. The fact that a 'rev bump' bug has not been submitted to date should answer your question, 'working with a slightly out-of-date version or upgrade break' ... go with the out-of-date version and close this bug. On the other side of the fence it looks to fix some pretty important bugs (cherry picked list of bugs), * 0.16rc2 2007-04-30 * Handle the case when you delete a file, and then rename another file on top of it. Also handle the case of ``bzr rm --keep foo``. ``bzr status`` should show the removed file and an unknown file in its place. (John Arbash Meinel, #109993) * Also handle when you rename a file and create a file where it used to be. (John Arbash Meinel, #110256) * 0.17rc1 2007-06-12 * Merge no longer fails when a file is renamed in one tree and deleted in the other. (Aaron Bentley, #110279) * 0.17 2007-06-18 * Fix crash of commit due to wrong lookup of filesystem encoding. (Colin Watson, #120647) * 0.18rc1 2007-07-10 * Work around python-2.4.1 inhability to correctly parse the authentication header. (Vincent Ladeuil, #121889) * Fix commit ordering in corner case (Aaron Bentley, #94975) * Make annotate behave in a non-ASCII world (Adeodato Simó). Me, I am new to Bazaar and I am trying to test it at my company ... so I will suffer no upgrade breakage. I choose to roll the new SPEC file because I had some problems with the 'rm' and 'mv' above as well as tag's in the tree. I did submit the same SPEC file to the Bazaar mailing list, I am not a member so it's waiting in some queue somewhere. Maybe the best thing is to see how many people respond to the Bazaar mailing list post?
Well, I've figured out a couple of options: 1) I can upgrade to 0.18 which is the last version before bzr installed arch specific files. Unfortunately, this release causes some issues with remote branches that have tags. 2) I can upgrade to 0.91 and disable the arch specific code... bzr has fallbacks to python-only code. This will result in a slower bzr because it doesn't have the compiled modules. It will also not be as well tested upstream as the architechture specific code. 3) I can go ahead with the upgrade even though it will break (potentially non-existent) unpackaged for Fedora plugins. Seeing as Fedora is a fast moving distro, I think that I'll go ahead with option #3. I'll officially build this in ~ a week when I move the F-7 package out of testing and into stable. For now, you can grab packages for testing from here: http://toshio.fedorapeople.org/bzr-packages/ If you are planning on running this on RHEL or CENTOS as well, I'll probably be doing #2 or #3 but it won't go out until the 5.2 push.
> If you are planning on running this on RHEL or CENTOS as well, I'll probably > be doing #2 or #3 but it won't go out until the 5.2 push. Bah. Let me clarify and fix that statement: I'll be upgrading the bzr packages in *EPEL* using either strategy #2 or #3 but not until *5.1* is pushed.
Packages built for FC-6 and F-7. They'll be in the repository after the next repository push.