[ATrpms-users] PIL vs. python-imaging? fftw2 vs. other fft flavors? etc..

[Jeffrey J. Kosowsky]

Jeffrey J. Kosowsky wrote at about 08:54:37 -0500 on Monday, January 7, 2008:
 > Axel Thimm wrote at about 13:02:13 +0200 on Monday, January 7, 2008:
 >  > On Mon, Jan 07, 2008 at 12:05:08AM -0500, Jeffrey J. Kosowsky wrote:
 >  > > I guess in summary, I am really asking for which (if any) of these can
 >  > > I revert to the Fedora base version without causing problems with the
 >  > > atrpms applications that depend on them?
 >  > 
 >  > I can't really answer that, as I know that the dependencies as set
 >  > forth in ATrpms do work and when/if I checked against the Fedora
 >  > version it didn't for one or another reason (zaptel and asterisk are
 >  > very good documented examples when they didn't).
 >  > 
 >  > In order to be able to answer this I would have to compare to every
 >  > change a Fedora maintainer does, especially from packages that are
 >  > being imported into Fedora after having a legacy of so many years in
 >  > other third party repos. I avoid introducing new packages that exist
 >  > elsewhere for the same reason.
 >  > 
 >  > That's also a reason why I'm trying to support as many ATrpms packages
 >  > as possible within Fedora itself. And the fact that improting a
 >  > package in Fedora takes about a year is not really helping here. :/
 >  > 
 >  > Note that for many packages where the chemistry between the Fedora
 >  > maintainer and myself worked out (by allowing ATrpms specific changes
 >  > to make it into the Fedora version, or at least providing proper
 >  > upgrade paths for ATrpms users) many packages have been withdrawn in
 >  > ATrpms' Fedora branch.
 >  > 
 >  > And another note for the future: The project that many 3rd party repos
 >  > from CentOS itself to Dag and also ATrpms, rpmrepo.org, will provide
 >  > facilities for users that do want a "pure" system to get what they
 >  > want by offering a server-side add-ons-only repo. Of course this means
 >  > that some packages relying on replacements will also not be in that
 >  > repo which is a natural conclusion, but users that follow this policy
 >  > will be fine. This targets more enterprise users that may have an SLA
 >  > with some support that does not allow too many vendor components to be
 >  > replaced. In that sense the RHEL5 part of ATrpms has moved all
 >  > replacement packages into ATrpms-testing. Which unfortunately breaks
 >  > some packages left behind in stable.
 >  > 
 >  > Anyway, hope this clears things up a bit.
 >  > 
 >  > BTW the non-replacement policy is often quoted when people want to
 >  > attack ATrpms (which you are not, I'm not implying this), but the
 >  > interesting part is that every repo including Fedora (Extras) in its
 >  > early fedora.us days replaced even system-deep packages like
 >  > shadow-utils, others (including ATrpms) replaced the buggy rpm itself,
 >  > so no one is really clean of doing replacements of system core
 >  > packages (for the better always!). At some time in RHL when
 >  > glibc-devel was broken even glibc was offered with a fix, other times
 >  > it was openssl.
 >  > 
 >  > And even though it is brought up that often it is (almost) always a
 >  > pure academic exercise. And the damage inflicted by a non-replacement
 >  > package is the same as introducing a bug in a replacement package.
 >  > -- 
 >  > Axel.Thimm at ATrpms.net
 >  > 
 >  > [GNUPG:] ERRSIG 401552D4639A99F1 17 2 01 1199703733 9
 >  > [GNUPG:] NO_PUBKEY 401552D4639A99F1
 > 
 > Axel,
 > Thanks very much for the very thoughtful response. As you pointed out,
 > I am certainly not attacking atrpms and personally I am a very big
 > fan and user of your work -- indeed, I am incredibly thankful for your
 > contributions and your very high level of responsiveness.
 > 
 > My motivation is more of an "Occam's razor"/simplicity one -- trying
 > to keep my system as clean and close to standard as
 > possible. This is particularly helpful so that when I do have a Fedora
 > problem, I don't get the "finger pointing" from the Fedora maintainers
 > that this is an atrpms problem (as happened with spamassassin).
 > 
 > While it may take some time and work, perhaps the best approach is one
 > you alluded to in your post. Divide the replacements into those that
 > truly diverge from Fedora philosophy and functionality and those that
 > don't and may be more there for historical reasons. 
 > 
 > For those that don't diverge too much, maybe set a medium term goal of
 > merging back into Fedora, including collaborating with the existing
 > maintainer where you have some minor (but not conflicting) tweaks. For
 > others, where atrpms has intentionally (and necessarily) taken a
 > different path, the best solution might be to flag the differences and
 > document what other atrpms depend on them (using an appropriately set
 > "Requires" flag). That way depending on how on sets up one's repo
 > prioritization, on can be sure to only get the atrpms that one truly
 > needs. (Again, maybe you are further down this path than I appreciate
 > or maybe I am just stating the obvious - if so, I apologize...)
 > 

Two further points -- First, one of the reason I held off from using atrpms as
my primary 3rd party repo for earlier releases of Fedora was that I
was often "scared-off" by the number of additional dependencies (or
replacements) required by atrpms vs. alternatives. Now this may be
irrational and the situation does seem to have improved, but I just
cite it as another advantage of keeping things as simple as
possible. And for me it is still true that when I am wavering on
whether or not to install a new application, I do look at how much
other "stuff" (both size and number of rpms) the dependencies draw in.

Second, another back-handed advantage of pushing to merge common rpms
back into Fedora core is that it would bring more of the bugs with the
existing rpms to light and push for common resolution. The more people
that are banging on the same common code, the more of a chance we have
to properly test and fix it.