Tim <ignored_mailbox@xxxxxxxxxxxx> writes: > On Fri, 2008-10-17 at 17:15 -0500, Marc Schwartz wrote: >> The problem typically is that you get a variety of upgrade related >> dependencies (eg. gtk) that can get too complicated to handle within a >> Fedora release, while those same dependencies are satisfied in the >> next release. >> > Surely, if Fedora can't do it as written above, you can't do it as > written below? >> >> Push comes to shove, you can always go upstream and get the latest >> version. I did that with OOo 3.0. > > Wouldn't you have the same dependency problems? Not necessarily. For example, the RPMS provided by OO.org for OOo 3.0 will not have the same explicit release version dependencies as the RPMS from Fedora. They are intentionally more flexible. This is intrinsic to the way in which the spec files for the RPMs are configured. The spec files can have release specific dependencies and you can find yourself in what has been known as 'dependency hell'. You find yourself having to install an increasing number of RPMS just to get a single application installed, because each new RPM that is required will in turn have its own set of intertwined dependencies. You can end up with a system which is ostensibly F9, but now has a fair number of rawhide/F10 RPMS installed, just to satisfy said dependencies. This is why you periodically see posts on the lists about adding or removing certain applications (Evolution tends to be popular), whereby there is a need to add or remove many seemingly unrelated RPMS. In addition, in many cases, Fedora maintainers will alter certain aspects of the upstream applications so that they 'fit' better with distro specific functionality. Thus, the OOo 3.0 rpms that are available in rawhide and F10 beta will not be exactly the same as those available from upstream, even for the same version. You can do this with other applications as well. For example, if you want to test beta versions of applications such as Firefox or Thunderbird, you can get the tarballs and add them to your system in such a fashion as they don't need the same rpm based dependencies. You can even install them in a way that you have both the standard Fedora version still available and have the ability to execute the upstream versions independently. Further, if you compile an upstream application from source (which for example, I do with Emacs 23 from their cvs and R from their svn), you can get around the explicit dependencies that would otherwise be in the RPMS. You may have to modify certain config options or similar, but in general, this approach is less subject to the vagaries of RPM based dependencies. HTH, Marc -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
