3 a.m.
The bittorrent (and bittorrent-gui) package has been downgraded in the
Extras development repo from version 5.0.5 to 4.4.0, due to
compatibility problems between the GUI and wxPython 2.8.x
(http://bugzilla.redhat.com/223623). Since bittorrent upstream is still
doing development on wxPython 2.6, there is little prospect of a fix for
this before FC7 release, so the package has been downgraded to the last
version that had a working (pygtk2-based) GUI.
As this is still the development phase of the release, the downgrade was
done without an epoch bump, so:
MANUAL DOWNGRADE WILL BE NEEDED IF YOU USE THE bittorrent PACKAGE ON
RAWHIDE.
Regards, Paul.
3:35 a.m.
Hi,
On Thu, 2007-03-01 at 09:00 +0000, Paul Howarth wrote:
The bittorrent (and bittorrent-gui) package has been downgraded in
the
Extras development repo from version 5.0.5 to 4.4.0, due to
compatibility problems between the GUI and wxPython 2.8.x
Thanks for ensuring that packages are usable; sometimes, sadly,
downgrading is the only option. Having said that...
As this is still the development phase of the release, the downgrade
was
done without an epoch bump, so:
MANUAL DOWNGRADE WILL BE NEEDED IF YOU USE THE bittorrent PACKAGE ON
RAWHIDE.
Can we please stop doing such things just because some people don't like
the Epoch being bumped? No-one have ever given good technical reasons
for this, only
- "it's ugly"; or
- "some software is broken and don't know about Epoch"; or
- "it's Rawhide, nobody should expect Rawhide to work"
To me it just seems, how shall I put it, non-constructive to put users
through a manual downgrade ordeal just to preserve one number that, for
the record, is meaningless already.
So, consider this a request for our various packaging committees to take
action and make our packaging guidelines reflect that we just don't do
things like this. Of course, if there exist technical reasons for not
bumping the Epoch, I don't pretend to be a packaging gure by any means,
that I'm not aware of I apologize for this noise.
Thanks.
David "I have an OCD about other people's OCD's" Zeuthen
7:01 a.m.
On Thu, 01 Mar 2007 04:35:59 -0500, David Zeuthen wrote:
Can we please stop doing such things just because some people
don't like
the Epoch being bumped? No-one have ever given good technical reasons
for this, only
- "it's ugly"; or
- "some software is broken and don't know about Epoch"; or
- "it's Rawhide, nobody should expect Rawhide to work"
To me it just seems, how shall I put it, non-constructive to put users
through a manual downgrade ordeal just to preserve one number that, for
the record, is meaningless already.
So, consider this a request for our various packaging committees to take
action and make our packaging guidelines reflect that we just don't do
things like this. Of course, if there exist technical reasons for not
bumping the Epoch, I don't pretend to be a packaging gure by any means,
that I'm not aware of I apologize for this noise.
A technical reason for avoiding Epochs is that at the RPM level, the
software version of a package is not independent from the package
version. When adding an Epoch to a package, the Epoch becomes a necessary
part of all forms of RPM version comparison. This introduces weaknesses in
non-automatic versioned dependencies and requires packagers to specify the
exact %{epoch} in all such dependencies to keep them strict.
Example:
Name: bar
Requires: foo >= 1.0
would be satisfied by
Name: foo
Version: 0.5
Epoch: 1
because due to the Epoch, the smaller %version wins RPM version comparison.
A solution to the problem would be to either avoid explicit dependencies
on versioned _package names_ or introduce more virtual capabilities of the
form
Provides: foo(api) = 1.0
Provides: foo(abi) = 1.0
which would remain free of Epochs.
10:49 a.m.
Michael Schwendt (mschwendt.tmp0701.nospam(a)arcor.de) said:
A technical reason for avoiding Epochs is that at the RPM level, the
software version of a package is not independent from the package
version. When adding an Epoch to a package, the Epoch becomes a necessary
part of all forms of RPM version comparison. This introduces weaknesses in
non-automatic versioned dependencies and requires packagers to specify the
exact %{epoch} in all such dependencies to keep them strict.
Example:
Name: bar
Requires: foo >= 1.0
would be satisfied by
Name: foo
Version: 0.5
Epoch: 1
because due to the Epoch, the smaller %version wins RPM version comparison.
However, these can be queried and accounted for when an epoch is
introduced. I'd agree with David - if we *can* make the upgrade path
clean, we should. Sometimes, there will be things that fail (horribly
broken %pre/%post scripts), but if the solution is clean (and adding
epoch where needed is clean), we should do it.
Bill
7:22 a.m.
On Thursday 01 March 2007 04:35:59 David Zeuthen wrote:
Can we please stop doing such things just because some people
don't like
the Epoch being bumped? No-one have ever given good technical reasons
for this, only
I'd really rather not introduce epochs before the final freeze point. I'm
perfectly happy with a policy that says no broken upgrade paths from the
final freeze on (be that Test3 or Test4), but before that one should be free
to back down a broken version. We don't seriously want people starting at
fc6 going to f7test1, then yum upgrading to some point before test3 and
complaining about some bug or such. The first thing we usually do is ask
them to reproduce on a clean install from the latest test release or a clean
anaconda upgrade from FX to the latest test release. The various state of
packages along the way often contribute to a system being in an
unreproducible state which doesn't help anybody when trying to fix bugs.
--
Jesse Keating
Release Engineer: Fedora
6:47 a.m.
Once upon a time Thursday 01 March 2007, Paul Howarth wrote:
The bittorrent (and bittorrent-gui) package has been downgraded in
the
Extras development repo from version 5.0.5 to 4.4.0, due to
compatibility problems between the GUI and wxPython 2.8.x
(http://bugzilla.redhat.com/223623). Since bittorrent upstream is still
doing development on wxPython 2.6, there is little prospect of a fix for
this before FC7 release, so the package has been downgraded to the last
version that had a working (pygtk2-based) GUI.
Why don't you add a compat-wxPython 2.6 if it works with that?
Dennis
7:10 a.m.
Dennis Gilmore wrote:
Once upon a time Thursday 01 March 2007, Paul Howarth wrote:
> The bittorrent (and bittorrent-gui) package has been downgraded in the
> Extras development repo from version 5.0.5 to 4.4.0, due to
> compatibility problems between the GUI and wxPython 2.8.x
> (http://bugzilla.redhat.com/223623). Since bittorrent upstream is still
> doing development on wxPython 2.6, there is little prospect of a fix for
> this before FC7 release, so the package has been downgraded to the last
> version that had a working (pygtk2-based) GUI.
Why don't you add a compat-wxPython 2.6 if it works with that?
The wxPython maintainer didn't think that a compat-wxPython26 package
was a particularly good idea, and would prefer to try to get the
wxPython 2.8 issues resolved instead:
http://www.redhat.com/archives/fedora-maintainers/2007-February/msg00633....
Paul.
6266
days inactive
6266
days old
6 comments
6 participants
participants (6)
-
Bill Nottingham -
David Zeuthen -
Dennis Gilmore -
Jesse Keating -
Michael Schwendt -
Paul Howarth