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

[Steven J. Long]

On Sat, May 10, 2014, Rich Freeman wrote:
> On Sat, May 10, 2014, hasufell wrote:
> > Longterm, this makes it year after year more difficult to develop
> > software for "Linux". Instead (like valve), people start to develop for
> > certain distros only (like Ubuntu), because it's just too much work to
> > bother with all this hackery-here-hackery-there-incompatible-here
> > things. Maybe also a reason they start to bundle all libraries for every
> > single game (among the convenience factor), effectively decreasing
> > security overall.
>
> I'm with you here, but what is the solution?

He outlined the solution and seemant resolved the implementation
"difficulty" question the day before your mail, amongst others, so
I'm unsure why it wasn't simply accepted. It seems like a no-brainer
to me, although it is a specific situation because lua is a language.
The latter is more relevant to consideration of whether they are
being unreasonable.

The solution is trivial and it means you're fixing the correct upstream.

> So, in your mind what would a sane policy look like?  Should packages
> like lua not provide pkg-config files even though apparently every
> other distro does?  If so, where do we draw the line?  Do we follow
> some particular distro like Debian?  Do we list 4 distros and allow
> the file if 3/4 use it?  If we don't allow a pkg-config in general can
> maintainers still have a "gentoo-foo" file?

If we don't provide it, period, there's no line to draw. I'm not saying
that applies to every package, but it self-evidently applies here,
and I agree with hasufell that it applies everywhere, if we want to do
more than follow the crowd for the sake of it, at the expense of our
reputation of helping upstreams fix their builds. The upstream with
the problem is more than happy to get a fix for the library they
depend on, and the patch is trivial.

Remember, no-one at all is talking about not shipping .pc; they're
only talking about fixing a midstream consumer of an upstream
which does NOT ship a .pc file. Is anyone seriously suggesting the
midstream do not want to work with their upstream in all situations?

> If we want a firm policy then there needs to be a proposal for one
> that makes sense.  Otherwise the council is 95% likely to just say "we
> recommend that maintainers use care when creating pkg-config files but
> we leave it to their discretion," because that is the only thing that
> makes any sense when you can't come up with a rule that makes sense.

The trouble with making general rules for specific situations is you
always have to account for the exception to every rule, and more:
keep reviewing the basis for the inevitable exceptions to see if they
still have standing. But it appears you already have a policy that
seems quite sane:

On Mon, May 12, 2014, hasufell wrote:
> I said repeatedly... if it is the ONLY way to fix something, then we
> have good reason to bend the rule. (and even then it should be made
> hard, as in: open this for discussion first. In addition, all of these
> non-upstream files have to be documented as such.)
>
> However, currently, this is not a rule, just some policy people would
> rather ignore since it might cause you a bit more work.

There does appear to be a trend to try to sideline the dev ML, on the
basis that "not all developers have to subscribe" which is rich coming
from one of its most prolific posters. Perhaps it's a phase, as istr
similar periods in the past. There are good reasons why drobbins made
the dev ML open to externals, who don't have a high rate of churn, and
why the GLEP process requires wider discussion on this same list.

I can think of several major changes that by all rights should have
gone through GLEPs, as well as being worked on in overlay. What
happened to the idea of getting professional results from an informal
group of volunteers dedicated to that end? Maybe i dreamt those years,
but some of your herds still manage it.

Regards,
steveL
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)