I have python-fedora 0.3.24-1.fc14 installed. Now if I run "yum update": Updating: python-fedora noarch 0.3.25.1-1.fc14.1 updates 358 k Installing for dependencies: [...snip...] Transaction Summary ========================================================================== Install 54 Package(s) Upgrade 1 Package(s) Why do I need 54 new packages installed that I didn't need before? What I need python-fedora for is usual Fedora packager tasks (basically only fedpkg, but also bodhi-client which gets pulled through fedora-packager which I suppose I could live without).
For reference, here's the list of those 54 new packages the update wants to pull in: Django MySQL-python PyGreSQL TurboGears TurboGears2 postgresql-libs python-cheetah python-cherrypy python-cherrypy2 python-configobj python-elixir python-formencode python-genshi python-kid python-markdown python-myghty python-nose python-paste-deploy python-paste-script python-peak-rules python-peak-util-addons python-peak-util-assembler python-peak-util-extremes python-peak-util-symbols python-prioritized-methods python-protocols python-psycopg2 python-pygments python-pylons python-repoze-tm2 python-repoze-what python-repoze-what-pylons python-repoze-who python-repoze-who-friendlyform python-repoze-who-testutil python-routes python-ruledispatch python-setuptools python-simplegeneric python-sqlite2 python-sqlobject python-tgfastdata python-toscawidgets python-transaction python-turbocheetah python-turbojson python-turbokid python-weberror python-webflash python-webhelpers python-webob python-webtest python-zope-interface python-zope-sqlalchemy
So here's the summary: python-fedora has been missing deps for a long time. This was pointed out to me and I looked into fixing it. As you see, adding the deps pulls a lot of packages that weren't required before. Those packages are needed for the server-support sections of the python-fedora code which not everyone needs. I created subpackages that keep the deps segregated in their own subpackages. Unfortunately, subpackages mean that if your package requires the TurboGears support, you need to change the Requires in your package to explicitly add it. A change that required other packages to change seemed contrary to the current Fedora updates policy. After much consideration, I decided to bend the rules slightly, announced that I was splitting the packages on F15 and greater (F14 being the oldest release at the time) and dependent packages needing the subpackages would have to be updated and rebuilt. I also announced that I would not be splitting F14 due to the concern that this violated the update policy. This still leaves the problem that the old python-fedora packages in F14 were missing deps. After receiving more queries about this, the deps were added the next time the upstream package was updated. This, of course, has lead to the opposite query -- why does python-fedora now pull in more packages? So I'm not sure what I want to do. The previous F14 packages were broken but only for a small number of users. The current F14 packages are pulling in more deps but so far, no one has raised this beyond the level of an inconvenience (python-fedora isn't included on the iso images, for instance, which is the one place I definitely know space is at a premium.) If you can let me know that the increased deps are actually causing a problem to counterbalance the actual problems that existed when the deps were not there and you can't upgrade to F15 or F16 where the subpackages exist to take care of this, I'll build new packages that once again have incomplete dependencies.
Similar situation for me - but *only* 41 additional packages! I have python-fedora installed for fedpkg - clone --anonymous, prep etc. - very useful when reporting bugs complete with a usable patch. If fedpkg had that original list of requirements I would not have installed it, and without fedpkg I'd be left struggling with bare git, curl and a web browser. The timing is also an issue - f14 will be end-of-life soon, so I'm trying to do a little garbage collection before upgrading. I would vote for a return to the previous, "broken" version that works for me and, I assume, other "anonymous client only" users. Thanks, as always, to the Fedora community, --DaveG.
Thanks for the thorough explanation. One thing which DaveG also noted that is not covered by it however is that was it actually necessary to push the update to F-14? Its EOL is in a few weeks. Isn't it likely that the vast majority of F-14 setups where the missing deps had been an issue have already fixed the issue locally by installing the missing deps they need? The number of newly installed F-14 setups where the missing deps would be an actual problem at this time (when we have 2 newer releases already available) is quite likely very very small. Regarding the question whether increased deps are actually causing a problem -- it is the generic reason why unnecessary dependencies are bad. To name a few: every package one has installed that one does not actually need means more unnecessary disk space usage, more unnecessary package updates to download, and more potential security issues lurking in the unnecessarily installed packages (if for some weird reason they end up being used somehow even though being unneeded). Personally, because the 0.3.25.1 update is not marked as a security one, I'm going to solve the issue by just adding exclude=python-fedora to my yum.conf and staying with 0.3.24 as long as I'm still using F-14 (will be moving on to F-16 soonish) unless something in it that I need stops working until then.
The update itself was necessary as there were bugs solved. The fixing of the deps issue didn't necessarily have to be pushed as part of that -- it was queued up along with new upstream releases but I was holding back on any updates to F14. After it became apparent that a new python-fedora package was necessary for F14 to fix bugs, the dep fixes went out too. The problem doesn't hit newly installed F14 setups. It hits any F14 setup where the user has not yet needed the server portions of the code. Once they start using it they suddenly don't have the deps they need. This is likely a small number, however, for some reason it seems that a large portion of Fedora Infrastructure devs (including the ones that are just starting work and thus encounter this problem) are running F14... At least, the number of reports I've received that the deps were broken implies that :-/. Since you're both running F14 as well, I suppose that F14 is just a popular release (or conversely, F15 was an unpopular release) across the board. In any case, F14 is nearing EOL as you say and I just want real bugs to be fixed and stay fixed. Broken deps are a real bug. If fixing them is an inconvenience I am sorry. If someone can give me a similar real issue (like a space constraint building F14 isos or OLPC images with python-fedora as one of the packages) I can consider this a bugfix as well. Otherwise, it's convenience vs correctness with the workaround of upgrading to F15 or F16 to have both convenience *and* correctness which is the route that is traditionally advocated.
My short-term fix: yum install yum-plugin-versionlock.noarch echo "0:python-fedora-0.3.24-1.fc14.noarch" >>/etc/yum/pluginconf.d/versionlock.list That should keep me (and yum) happy until I can upgrade to F16. --DaveG.
Closing this as F14 is no longer supported and the other Fedora releases had proper subpackages to separate out deps.