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

[Axel Thimm]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.atrpms.net/pipermail/atrpms-users/attachments/20080107/76ac6ed6/attachment.bin