Bug 563984 - Latest version of transmission fails to install from repos
Summary: Latest version of transmission fails to install from repos
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: PackageKit
Version: 11
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Richard Hughes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 556007 564415 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-02-11 16:45 UTC by Jonathan Ryshpan
Modified: 2010-03-22 17:00 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-03-22 17:00:45 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Jonathan Ryshpan 2010-02-11 16:45:03 UTC
Description of problem:
Latest version fails to install from repos.

Version-Release number of selected component (if applicable):
1.83-1

How reproducible:
Always.

Steps to Reproduce:
1. run gpk-update-viewer
2. box says that transmission (2 packages) needs updating
3. select both, click "Install Updates"
4. box appears saying that Transmission Common Files needs to be installed
5. click install
  
Actual results:
Error box appears saying 
"Transaction Error
could not add package update for 
transmission-1.83-1.fc11(x86_64)updates: 
transmission-1.83-1.fc11.x86_64

Expected results:
Transmission is updated

Additional info:

Comment 1 Rahul Sundaram 2010-02-11 17:00:19 UTC
This sounds more like a Packagekit issue  Try

# yum update transmission

Comment 2 Richard Calmbach 2010-02-14 05:04:06 UTC
I'm on Fedora 12 x86_64 and I'm getting a corresponding error dialog: "could not add package update for transmission-1.83-2.fc12(x86_64)updates: transmission-1.83-2.fc12.x86_64" (see 1st comment by rcalmbac at [1]).

I noticed in Koji that both package transmission ([2]) and package transmission-gtk ([3]) have a "Provides" for "transmission 1.83-2.fc12". That doesn't look right. Either "transmission-gtk" really does obsolete "transmission" - then there should no longer be a package transmission-1.83-2.fc12 - or package transmission-gtk should not have the "Provides" for "transmission". Wouldn't surprise me if this is what's confusing PackageKit. I haven't executed the update with yum because I'd rather wait until these packaging problems are resolved than risk corrupting my yum DB. Suffice it to say that for "yum upgrade transmission" up to the "[y/N]" prompt I get the same output (with version adjusted) as Michal Schmidt in bug 556007:

# yum upgrade transmission

================================================================================
 Package                   Arch         Version             Repository     Size
================================================================================
Installing:
 transmission-gtk          x86_64       1.83-2.fc12         updates       579 k
     replacing  transmission.x86_64 1.77-1.fc12

Installing for dependencies:
 transmission-common       x86_64       1.83-2.fc12         updates       385 k

Transaction Summary
================================================================================
Install       2 Package(s)
Upgrade       0 Package(s)

Total download size: 964 k
Is this ok [y/N]:

-------------

Given that there is this RPM metadata problem I'm actually surprised that yum doesn't scream bloody murder.

The package name on the transmission-gtk RPM page at [3] links to the package page for transmission (ID 4013) and there is currently no package page in Koji for transmission-gtk (search doesn't find one). Again, this doesn't look right.

According to [2], RPM transmission-1.83-2.fc12 has no files. I'm not sure what its role is then. It looks like package transmission was split into transmission-cli and transmission-gtk in order to remove GTK dependencies from the command line version (I'm guessing). Somewhere along the way package metadata seems to have gotten mangled.

Ref.:
[1] https://admin.fedoraproject.org/updates/F12/FEDORA-2010-1521
[2] http://koji.fedoraproject.org/koji/rpminfo?rpmID=1801918
[3] http://koji.fedoraproject.org/koji/rpminfo?rpmID=1801922

Comment 3 Ankur Sinha (FranciscoD) 2010-02-14 06:56:32 UTC
*** Bug 564415 has been marked as a duplicate of this bug. ***

Comment 4 Ankur Sinha (FranciscoD) 2010-02-14 06:57:34 UTC
*** Bug 556007 has been marked as a duplicate of this bug. ***

Comment 5 Rahul Sundaram 2010-02-14 07:16:16 UTC
transmission is currently a metapackage that provides a update path and it is fully expected that a meta package by itself wouldn't have any files  The provides/obsoletes takes care of the update path for various split up sub packages  The fact that yum works fine is proof that the problem has nothing to do with transmission but packagekit  

Reassigning

Comment 6 Richard Calmbach 2010-02-14 09:27:02 UTC
Hmm, I'm not convinced that the transmission packages are kosher. Upon "yum upgrade", the new package transmission-1.83-2.fc12 does not get pulled from the repo, whereas I suspect on a system where transmission is not yet installed doing a "yum install transmission" *will* pull transmission-1.83-2.fc12 and its dependencies. This asymmetry smells fishy. E.g., after upgrading, /usr/bin/transmissioncli and /usr/bin/transmission-daemon have disappeared and only an explicit "yum install transmission" or "yum install transmission-cli" will bring /usr/bin/transmissioncli back and only an explicit "yum install transmission-daemon" will bring /usr/bin/transmission-daemon back. Let me emphasize that explicit installs are required, a "yum upgrade" will not do it.

I maintain that the "Provides transmission" in package transmission-gtk is wrong, and so is probably the "Obsoletes transmission". Why not just have the new, empty transmission-1.83 package be the update to transmission-1.77, with some new dependencies (transmission-cli, transmission-gtk, transmission-daemon, and indirectly transmission-common) along for the ride? That would yield the expected update path with no missing pieces after upgrading and fresh installs would work, too.

I'm not an expert on RPM or yum but I'm curious to see what others with more package tools experience have to say on this.

Also, is it intentional that package transmission no longer includes (directly or via any dependency) /usr/bin/transmission-daemon? I don't see anything in the discussion at bug 550976 that suggests that this was part of the plan.

Comment 7 Rahul Sundaram 2010-02-14 09:40:43 UTC
I will explain it one more time but if you need to learn packaging this bugzilla report isn't the right place for that:

Previously transmission was a single package and it has now been split up into multiple sub packages and transmission itself is merely a meta package to provide an update path and have something for users to pull in   

The meta package will only pull in -gtk and -cli and yes it is desires that the daemon is not installed by default and only when transmission-daemon is explicitly installed 

If you need more information feel free to email me instead of cluttering up all the different bug reports with similar comments

Comment 8 Richard Calmbach 2010-02-14 10:25:02 UTC
Look, I'm just trying to help. I'm not even using transmission, I was just doing a regular upgrade and ran into problems. I spent way more time on this than I wanted to. I saw the different bug reports, noticed that they were all related to the same problem, and added comments to tie them together. If I had the necessary privileges I would have marked them as duplicates myself, as Ankur Sinha has done as a result of my efforts.

This is not the kind of attitude that makes people feel welcome to join the Fedora community. I am not cluttering up bug reports, I am making connections as good as I can to help out those who are in a position to solve the problem. Please recognize that.

Until you stated it explicitly, it was not clear that the loss of transmissioncli and transmission-daemon upon upgrade is intentional - and I read all the related bug reports. So, thanks for clearing that up.

Comment 9 Rahul Sundaram 2010-02-14 10:37:44 UTC
Commenting in each and every related bug report is certainly not going to be helpful to me as a maintainer and you continue to insist there are bugs after misunderstanding a number of things and while I appreciate you trying to help but this is not the right approach for that 

Bugzilla is not very suitable as a medium for such discussions and if you wish to continue you are free to email me as I have already offered

Comment 10 Richard Calmbach 2010-02-14 14:15:17 UTC
The repackaging was poorly handled. If there had been proper documentation about the unusual change (dropping two executables mid-release just by doing "yum upgrade"), there would not have been all this confusion in the first place. So, the lesson here is that it is generally not a good idea to do this kind of repackaging and dropping of functionality mid-release when users don't expect it. That kind of thing always leads to surprises and confusion. Users are prepared for repackaging and loss of functionality when going from one distro release to another, but not intra-release.

If I hadn't added my initial comments, the connections between the different bug reports wouldn't have been apparent because they were all against different components. Someone else would have had to do that work. I did it for our collective benefit, so we can move forward and get these issues resolved - you cannot possibly have a problem with that!!!

Seriously, dude, you need to tone down the confrontational attitude. I want to see Linux in general and Fedora in particular succeed on a wide scale and that requires extending the community beyond us hard-core tech geeks who are used to the testosterone-laden banter. I recommend Fedora to my friends because it's a great, stable distro, but sometimes I get feedback that they were trying to ask a question on the mailing lists but were too scared because of the aggressive tone there. Believe it or not, this is also one of the main reasons why so few women participate in open source. It can't hurt Fedora to become a more inclusive community. I would think that is something we can all agree on.

Comment 11 Rahul Sundaram 2010-02-14 15:08:29 UTC
I don't see any general confusion from end users and I see you have been confused but since you are not a user of transmission I suppose that is not unexpected  There is zero loss of functionality and sub packages have actually increased the functionality by providing a init script and config file among other things explicitly requested from users of transmission

The comments were all against the same component called transmission for which I am the maintainer and while your intention are goods it would be better for us to address the real problems  Thanks

Comment 12 Richard Calmbach 2010-02-14 16:27:48 UTC
The point is that a straightforward "yum upgrade" does result in loss of functionality. That is something best avoided mid-release and it has nothing to do with whether I am a user of that package or not - it's just common sense. That this sort of thing causes surprises and confusion is a general statement and as such is born out by many examples both within and beyond Fedora.

I added comments to these bugs:

bug 550976 - component transmission
bug 564415 - component yum-updatesd
bug 556007 - component gnome-packagekit

and this one, now component PackageKit (originally transmission). That's not all the same component as you claim. Please get your facts straight.

Addressing the real problem is all I set out to do but I guess you can't please everyone. Thank you though for being so responsive as a package maintainer. That kind of quick turnaround is what makes open source rock!

Comment 13 Rahul Sundaram 2010-02-15 06:35:06 UTC
To satisfy the requests of users the split was done and since almost all users of transmission currently use the gtk interface there is no loss of functionality and the current update was done after careful testing and explicit feedback from transmission users and yes I indeed can't please everyone


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