Bug 308091 - Revision Bump of Bazaar (bzr) to 0.90
Revision Bump of Bazaar (bzr) to 0.90
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: bzr (Show other bugs)
6
All Linux
low Severity medium
: ---
: ---
Assigned To: Toshio Ernie Kuratomi
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 308101
  Show dependency treegraph
 
Reported: 2007-09-26 17:30 EDT by Michael S. Chaffin
Modified: 2007-11-30 17:12 EST (History)
1 user (show)

See Also:
Fixed In Version: 0.91-1.fc6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-05 20:14:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
First cut at bzr 0.90 SPEC file (46.31 KB, text/plain)
2007-09-26 17:30 EDT, Michael S. Chaffin
no flags Details

  None (edit)
Description Michael S. Chaffin 2007-09-26 17:30:25 EDT
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.
Comment 1 Michael S. Chaffin 2007-09-26 17:30:25 EDT
Created attachment 207621 [details]
First cut at bzr 0.90 SPEC file
Comment 2 Toshio Ernie Kuratomi 2007-09-26 18:27:27 EDT
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.
Comment 3 Toshio Ernie Kuratomi 2007-09-26 19:33:57 EDT
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.
Comment 4 Michael S. Chaffin 2007-09-27 11:31:30 EDT
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?
Comment 5 Toshio Ernie Kuratomi 2007-09-28 13:09:39 EDT
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.
Comment 6 Toshio Ernie Kuratomi 2007-09-28 13:12:17 EDT
> 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.
Comment 7 Toshio Ernie Kuratomi 2007-10-05 20:14:16 EDT
Packages built for FC-6 and F-7.  They'll be in the repository after the next
repository push.

Note You need to log in before you can comment on or make changes to this bug.