On Thu, 31 Aug 2006 22:34:56 -0500
"Boyd Stephen Smith Jr." <[EMAIL PROTECTED]> wrote:

> On Thursday 31 August 2006 11:31, "Duncan" <[EMAIL PROTECTED]>
> wrote about '[gentoo-amd64]  Re: About gcc 4.1.1':
> > "Boyd Stephen Smith Jr." <[EMAIL PROTECTED]> posted
> > [EMAIL PROTECTED], excerpted below, on  Thu,
> > 31 Aug
> >
[...]
> > If Gentoo, that's exactly what the various replace-flags and
> > filter-flags do, at the Gentoo level, which is the ebuild.
> 
> No, they don't make the package work with my flags; they
> ignore/change my flags so that the package works.

The job of Gentoo ebuild Developers is to provide an ebuild that will
generate a package that (ideally) "just works", in a supported
environment (i.e. one of the supported profiles with sensible CFLAGS
etc).  It is _not_ the job of ebuild devs to go hacking around in the
upstream code to support compilation with any old set of wacky CFLAGS.

So, doing "replace-flags -O? -O2" is exactly what ebuild devs should do
if a package doesn't work when built with other optimisation levels.
Strictly speaking, if there are bugs in an application that are not the
result of the Gentoo environment being different to upstream, the only
thing Gentoo ebuild devs need to do is file a suitable bug upstream and
wait for upstream to provide a patch.

Obviously, in practice we do patch code.  Frequently this means just
applying patches that come from upstream.  Sometimes we do develop
patches, if there is someone around who is competent to do so, in which
case we send the patches upstream so the fix can be incorporated (at
which point upstream may well re-work it).  Sometimes the patching is to
support environments that are unusual, for example the hardened
profiles which change the environment in ways that upstream usually
don't expect. Sometimes the patching is to support environments that
upstream don't explicitly test, for example different arches.

However Gentoo is not in the business of package development - it is in
the business of system integration; putting all the packages together
in a way that works.

-- 
Kevin F. Quinn

Attachment: signature.asc
Description: PGP signature

Reply via email to