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

[Jeffrey J. Kosowsky]

Axel Thimm wrote at about 21:48:34 +0200 on Monday, January 7, 2008:
 > On Mon, Jan 07, 2008 at 09:27:24AM -0500, Jeffrey J. Kosowsky wrote:
 > >  > 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. 
 > 
 > Actually the cut will be 100% non-replacements, e.g. pure add-ons, and
 > a full repo. There will not be made any distinction about whether some
 > replacement packages are better than others etc. The reason this
 > split will happen is to give users a server-side method to comply with
 > their policy, as all the selective/partial enabling of repos on the
 > client side are doomed to fail.
 > 
 > If someone wants to help out (but this is stuff for atrpms-devel or
 > rpmrepo-devel) it would be great to have some automatic treatment of
 > subrepos that will detect dependent packages to remove as well from a
 > subset of the repo. Also an automatic detection of duplicates would be
 > great to have as well, as moniting some repo on whether a package was
 > imported or not is not really possible with sane human resources. For
 > example if package foo is suddenly in some vendor repo it needs to
 > automigrate away from the pure add-ons repos as well as any dependent
 > on this package (unless the vendor's package stisfies the requirements
 > - this can't be done by a machine but indeed needs human
 > intelligence).
 > 
 > But this really diverts into atrpms-devel/rpmrepo-devel, so if anyone
 > is interested in venturing into this, please followup there, thanks!
 > 
 > >  > 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...)
 > 
 > I attacked this with great enthusiasm before FC5 was released. The
 > problem was that out of say 10-20 people out of the Fedora
 > maintainers' group needed for this only 1-2 embraced this. I
 > reattacked it a year or so ago, I think before/after F7's release and
 > had the same unpleasent response.
 > 
 > So if it sounds like waiting too long for a new package to enter
 > Fedora, it takes even longer to have custom changes applied to a
 > package for compatibilities sake. Just look at my ivtv firmware
 > submission where some compatibility links needed for older install or
 > RHEL is being criticized on and stall the approval. :/
 > 
 > > 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.
 > 
 > Sure, that's what I do as well. But that's another topic. I can't
 > reduce the dependencies of say the "mythtv" metapackage that is
 > supposed to pull in everything you *could* need as it applied to North
 > America or Europe or some other locale.
 > 
 > > 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.
 > 
 > Agreed, all bug I encounter with Fedora are either rpeorted by myself
 > or I ask people to resubmit the bug there and I often mentor the bug
 > at Fedora. A lot of selinux bugs come to mind, where for example the
 > Fedora maintainer is giving great feedback.
 > 
 > At the end it boils down to how people interoperate and to how much
 > time one can invest in trying to improve Fedora within Fedora. It
 > turns out that I could invest a whole year worth of ATrpms' time
 > (e.g. do nothing at ATrpms for a year) and I would still not have even
 > half the packages fixed as they are needed to.
 > 
 > As I wrote I often attacked this and I even tried to get higher organs
 > within Fedora to give a green light to pave the way for something like
 > this (FWIW I even joined the Fedora packaging commitee to allow for
 > kmdls to enter Fedora, but some black Fedora sheep torpedoed this),
 > but I just wasted tons of time better invested in improving packages
 > at ATrpms or packaging new stuff (or meeting with my family ;).
 > 
 > So at the end I will offer the pure add-on repo to satisfy the
 > appropriate requests (mostly due to the enterprise target groups, but
 > the consuming group will benefit from the same setup), be able to
 > react to any bug/required feature within the repo and still be able to
 > fire off bugzilla improvements for Fedora proper.
 > -- 
 > Axel.Thimm at ATrpms.net
 > 
Thanks for the comprehensive and thoughtful reply.
It seems like it's a shame that the Fedora group does not take yours
(and presumably others') input as constructively as they should.