Bug 308091

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.