[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Why does it take so long for new (gimp, kernels, openoffice) packages to reach the stable repo ?

Tim <ignored_mailbox yahoo com au> 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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]