Re: [gentoo-dev] Re: Banning modification of pkg-config files

[Rich Freeman]

On Sat, May 10, 2014 at 9:00 AM, hasufell <hasufell@g.o> wrote:
>
> Our philosophy states that our tools "should be a joy to use". If we add
> random hackery on stuff that affects portability across distros, then
> this doesn't hold true anymore.
>

Which one of our tools is at risk of not being a joy to use?  All of
the tools we're talking about here have no origin in Gentoo.

It sounds like the impact is to upstream developers who use Gentoo not
realizing that a library they depend on doesn't actually provide a
pkg-config file across all distros.  How large an issue is this in
practice?  It sounds like somebody will build something which works
fine in their testing, and then somebody will get a compiler error on
some other distro and report it, and then they can take 2min to fix
their build system once and for all.

What solutions do we have?  Obviously we should try to get upstream to
change, but when they don't I don't see a universal policy that makes
sense.

We could ban non-upstream pkg-config files entirely, in which case
build systems that work for every other distro that supplies them may
fail on Gentoo and we need to patch them (and for users building their
own software that hardly sounds like a joy to use).  Or we could force
them to be renamed to gentoo-foo, in which case again build systems
that work fine for every other distro that doesn't do this fail on
Gentoo.  Or we could leave it up to the maintainer, in which case we
basically end up with what we have today.

I could see guidelines, but even those are going to be hazy.  Maybe
recommend using a gentoo prefix on the pkg-config file when we're the
only distro doing something.  However, then we run into the prefix
changing on a later release and then reverse dependencies break.

We could have a USE flag which blocks installation of non-upstream
pkg-config files.  Of course, it might not be practical to use since
anything which depends on the library in question might force it to
not be set so that its own build system can rely on it.  Sure, we
could patch the build system to not require it, but most likely the
build system does require it is that it is common on other distros so
we're the ones standing alone.

So, while I agree that the current state isn't ideal, I'm not sure
that it is any worse than the alternatives.

Rich