[gentoo-dev] Re: Banning modification of pkg-config files (was: [gentoo-project] Re: Call For Agenda Items - 13 May 2014)

[gentoo-dev] Re: Banning modification of pkg-config files (was: [gentoo-project] Re: Call For Agenda Items - 13 May 2014)

[Matti Bickel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 05/09/2014 04:07 PM, hasufell wrote:
> I ask the council to vote on banning pkg-config files that would
> be added or renamed downstream (at least this will prevent new
> violations).

I want to repeat my stance from the linked bug that making this a
policy or calling on council to add more weight to existing devmanual
bits is adding red tape that from my point of view decreases the
quality of Gentoo. Asking me to remove the pkg-config file for lua-5.2
or removing the modifications to 5.1 will kill support for packages
depending on these files existing.

As long as there's stuff expecting the file to be around, I have a
hard time committing a "fix" that will increase the breakage in the tree.

Let me be clear: once packagers of lua using apps tell me they no
longer need the .pc file for their stuff to work, I'll remove it
promptly or switch to the reduced version you get from calling "make
pc" for lua-5.2.

However, all the linked bugs and commits seem to address the point
that debian *renames* the lua .pc files. You seam to take particular
issue with slotting lua (which requires us to rename them as well).

I'm on the record saying that I don't like this solution. However,
I've made it clear (and the eselect-lua module implements this) that
there's always a lua.pc, liblua.so, etc of the user's chosing. It's
also the only thing we got to resolve the stalemate of lua users
lagging behind releases. If you have better ideas, please let me know.

Since this is a technical matter, please direct further discussion to
the gentoo-dev ML.

Cheers, Matti
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJ8BAEBCgBmBQJTbRyhXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNzE1M0M4QzQxMzM4REREMjMzQjg4NUZE
REY5NzFGMTE4RUVBNUU2AAoJEN35cfEY7qXmEGsP/39WprTJ9T4FmBiNO+xnPDS5
H3FbNmdN/YjyOy5OSBMbS2j9fxQXEJ5AdAeE5gWyEiNEji0wmecWqP2FNAEtoZ5c
H4IJ92eSyw99zz424GU2eS0uNCkujn/xOIxWHmrvWiCiUYzF150KHl9nrRRdRrwB
dKjyz7nXiEyZDS1dQ4gyTMeA6mUIrr0bFl0G8Kfy0dPWB0elpe837no/S/fRcKtM
syb9+QL3TvYlCVbONkcFxtOQyij+9OTcMffITVysiHjy5+CNKoVjw3zKUPoYQN1f
CSdob9x/W+vUrZt1gjEbxukqyBMlBokapvN1nwwi7T6IczHCPpDtnvN6TncX/0VW
AkwB5wAgtxjsf6bu8vvx6D6gRYDoYFgXHe81m+SHfmbkDaIAUk67QdN3WHg4R0o7
fgJ5KVx5KowemNdM3SybJlTTOkt6ROaqkzMRsXDC+vDwQEZ4881zLpttGFfEJPjR
tfej+FrhoMv5yir8joUIePwXLXluF1D0DO8RlrUpGTAFkwY1QqdA0ho3rwRpDZDT
70iWKepz6Xgj7mKlVjSF6C5iPxyKYMbgVgH+4IK4MCWYvam/tLwtbuegDmF/txUM
5P4a4fQUzvmGFmDOkRsnJBj5Gnez8J5DxzB3hmRJgT+TVKxlfRCQ4Ajh31VHQXun
nw5cxcrYETn9jQtdmbqJ
=JnYK
-----END PGP SIGNATURE-----

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

[Markos Chandras]

Hi,

(please avoid cross-list e-mails in the future if possible. Makes
threading horrible)

On 05/09/2014 07:21 PM, Matti Bickel wrote:
> On 05/09/2014 04:07 PM, hasufell wrote:
>> I ask the council to vote on banning pkg-config files that would
>> be added or renamed downstream (at least this will prevent new
>> violations).
> 
> I want to repeat my stance from the linked bug that making this a
> policy or calling on council to add more weight to existing devmanual
> bits is adding red tape that from my point of view decreases the
> quality of Gentoo. Asking me to remove the pkg-config file for lua-5.2
> or removing the modifications to 5.1 will kill support for packages
> depending on these files existing.
> [...]

I was wondering, is there a good reason we keep our own pkgconfig files
instead of communicating that to upstream and resolve that properly?
What other distributions do? Or are we a special case and we need our
own pc files?

-- 
Regards,
Markos Chandras

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

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 799 bytes --]

On Fri, 09 May 2014 20:57:29 +0100
Markos Chandras <hwoarang@gentoo.org> wrote:

> I was wondering, is there a good reason we keep our own pkgconfig
> files instead of communicating that to upstream and resolve that
> properly?

Yes, when your "instead of ..." is not an option.

> What other distributions do? Or are we a special case and
> we need our own pc files?

No, see https://bugs.gentoo.org/show_bug.cgi?id=509392#c23 which reads:

    "You do realize that out of five distros (Fedora, Debian,
    Slackware, SuSe, Mandriva) I checked five ship a .pc file?" by mabi.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Markos Chandras]

On 05/09/2014 09:08 PM, Tom Wijsman wrote:
> On Fri, 09 May 2014 20:57:29 +0100
> Markos Chandras <hwoarang@gentoo.org> wrote:
> 
>> I was wondering, is there a good reason we keep our own pkgconfig
>> files instead of communicating that to upstream and resolve that
>> properly?
> 
> Yes, when your "instead of ..." is not an option.

Why not? If the package does not work out of the box then something is
broken upstream? If it works for Debian but not for us then maybe we do
something wrong? Otherwise, if having our own pc files (assuming there
is no abuse here and we touch reverse deps only when really necessary)
why is that a problem?

I fail to understand the problem here.

> 
>> What other distributions do? Or are we a special case and
>> we need our own pc files?
> 
> No, see https://bugs.gentoo.org/show_bug.cgi?id=509392#c23 which reads:
> 
>     "You do realize that out of five distros (Fedora, Debian,
>     Slackware, SuSe, Mandriva) I checked five ship a .pc file?" by mabi.
> 

I am not talking about Lua here. It's a more general question.

-- 
Regards,
Markos Chandras

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

[Rich Freeman]

On Fri, May 9, 2014 at 4:08 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
> On Fri, 09 May 2014 20:57:29 +0100
> Markos Chandras <hwoarang@gentoo.org> wrote:
>
>> I was wondering, is there a good reason we keep our own pkgconfig
>> files instead of communicating that to upstream and resolve that
>> properly?
>
> Yes, when your "instead of ..." is not an option.
>
>> What other distributions do? Or are we a special case and
>> we need our own pc files?
>
> No, see https://bugs.gentoo.org/show_bug.cgi?id=509392#c23 which reads:
>
>     "You do realize that out of five distros (Fedora, Debian,
>     Slackware, SuSe, Mandriva) I checked five ship a .pc file?" by mabi.

I think fixing upstream is a no-brainer.  The controversy only exists
when upstream refuses to cooperate (which seems to be the case when
we're one of six distros patching it).  If there are other situations
where we supply our own files please speak up.

When the only issue is maintainer laziness I could see fixing that in
a different way...

Rich

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

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1760 bytes --]

On Fri, 09 May 2014 21:10:50 +0100
Markos Chandras <hwoarang@gentoo.org> wrote:

> On 05/09/2014 09:08 PM, Tom Wijsman wrote:
> > On Fri, 09 May 2014 20:57:29 +0100
> > Markos Chandras <hwoarang@gentoo.org> wrote:
> > 
> >> I was wondering, is there a good reason we keep our own pkgconfig
> >> files instead of communicating that to upstream and resolve that
> >> properly?
> > 
> > Yes, when your "instead of ..." is not an option.
> 
> Why not? If the package does not work out of the box then something is
> broken upstream?

Some upstreams don't care about Gentoo's practices like slotting and/or
dynamic linking; similarly, similar practices on other distributions.

> If it works for Debian but not for us then maybe we do something
> wrong?

This mixes two things. It currently works for the Lua maintainers, as
those pkgconfig files are present; just like they are present on Debian.

> >> What other distributions do? Or are we a special case and
> >> we need our own pc files?
> > 
> > No, see https://bugs.gentoo.org/show_bug.cgi?id=509392#c23 which
> > reads:
> > 
> >     "You do realize that out of five distros (Fedora, Debian,
> >     Slackware, SuSe, Mandriva) I checked five ship a .pc file?" by
> > mabi.
> > 
> 
> I am not talking about Lua here. It's a more general question.

Ah, I see; it's just that we come from the Lua context background, so
it'll often be used as example. As for in general, we'll indeed need to
investigate what other distributions do; but, Lua is that special case.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1140 bytes --]

On Fri, 9 May 2014 16:15:58 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> I think fixing upstream is a no-brainer.

It indeed is, this is the goal; you can force them in multiple ways,
some of which can be found on the Lua bug and previous discussion(s).

> The controversy only exists when upstream refuses to cooperate (which
> seems to be the case when we're one of six distros patching it).  If
> there are other situations where we supply our own files please speak
> up.

Not that I know of; the refusal to cooperate is what this is all about,
see my last response to hwoarang before this mail for a short summary.
Though, I think that the Lua maintainers can explain all the details...

> When the only issue is maintainer laziness I could see fixing that in
> a different way...

It has always been an issue; we could always use more manpower, ...

https://wiki.gentoo.org/wiki/Contributing_to_Gentoo

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Markos Chandras]

On 05/09/2014 09:32 PM, Tom Wijsman wrote:
> On Fri, 9 May 2014 16:15:58 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
> 
>> I think fixing upstream is a no-brainer.
> 
> It indeed is, this is the goal; you can force them in multiple ways,
> some of which can be found on the Lua bug and previous discussion(s).
> 
>> The controversy only exists when upstream refuses to cooperate (which
>> seems to be the case when we're one of six distros patching it).  If
>> there are other situations where we supply our own files please speak
>> up.
> 
> Not that I know of; the refusal to cooperate is what this is all about,
> see my last response to hwoarang before this mail for a short summary.
> Though, I think that the Lua maintainers can explain all the details...
> 
>> When the only issue is maintainer laziness I could see fixing that in
>> a different way...
> 
> It has always been an issue; we could always use more manpower, ...
> 
> https://wiki.gentoo.org/wiki/Contributing_to_Gentoo
> 

Well to me it feels that gentoo specific .pc files is a similar problem
to any other patch that affects upstream code in order to make the
package compatible with gentoo. Some people may consider downstream pc
files more dangerous because reverse deps are affected. But really, if
there is no other alternative, we shouldn't be treating this as a
special case. We patch upstream packages all the time after all

-- 
Regards,
Markos Chandras

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

[Ben de Groot]

On 10 May 2014 04:34, Markos Chandras <hwoarang@gentoo.org> wrote:
> On 05/09/2014 09:32 PM, Tom Wijsman wrote:
>> On Fri, 9 May 2014 16:15:58 -0400
>> Rich Freeman <rich0@gentoo.org> wrote:
>>
>>> I think fixing upstream is a no-brainer.
>>
>> It indeed is, this is the goal; you can force them in multiple ways,
>> some of which can be found on the Lua bug and previous discussion(s).
>>
>>> The controversy only exists when upstream refuses to cooperate (which
>>> seems to be the case when we're one of six distros patching it).  If
>>> there are other situations where we supply our own files please speak
>>> up.
>>
>> Not that I know of; the refusal to cooperate is what this is all about,
>> see my last response to hwoarang before this mail for a short summary.
>> Though, I think that the Lua maintainers can explain all the details...
>>
>>> When the only issue is maintainer laziness I could see fixing that in
>>> a different way...
>>
>> It has always been an issue; we could always use more manpower, ...
>>
>> https://wiki.gentoo.org/wiki/Contributing_to_Gentoo
>>
>
> Well to me it feels that gentoo specific .pc files is a similar problem
> to any other patch that affects upstream code in order to make the
> package compatible with gentoo. Some people may consider downstream pc
> files more dangerous because reverse deps are affected. But really, if
> there is no other alternative, we shouldn't be treating this as a
> special case. We patch upstream packages all the time after all

Exactly. I don't understand why this is an issue at all. Obviously,
if upstream does not ship a .pc file or ships a broken one, we try
to work with upstream to get it fixed on their end. If they are
uncooperative, we fix it on our end.

-- 
Cheers,

Ben | yngwin
Gentoo developer

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

[Alexandre Rostovtsev]

[-- Attachment #1: Type: text/plain, Size: 2557 bytes --]

On Sat, 2014-05-10 at 13:50 +0800, Ben de Groot wrote:
> On 10 May 2014 04:34, Markos Chandras <hwoarang@gentoo.org> wrote:
> > On 05/09/2014 09:32 PM, Tom Wijsman wrote:
> >> On Fri, 9 May 2014 16:15:58 -0400
> >> Rich Freeman <rich0@gentoo.org> wrote:
> >>
> >>> I think fixing upstream is a no-brainer.
> >>
> >> It indeed is, this is the goal; you can force them in multiple ways,
> >> some of which can be found on the Lua bug and previous discussion(s).
> >>
> >>> The controversy only exists when upstream refuses to cooperate (which
> >>> seems to be the case when we're one of six distros patching it).  If
> >>> there are other situations where we supply our own files please speak
> >>> up.
> >>
> >> Not that I know of; the refusal to cooperate is what this is all about,
> >> see my last response to hwoarang before this mail for a short summary.
> >> Though, I think that the Lua maintainers can explain all the details...
> >>
> >>> When the only issue is maintainer laziness I could see fixing that in
> >>> a different way...
> >>
> >> It has always been an issue; we could always use more manpower, ...
> >>
> >> https://wiki.gentoo.org/wiki/Contributing_to_Gentoo
> >>
> >
> > Well to me it feels that gentoo specific .pc files is a similar problem
> > to any other patch that affects upstream code in order to make the
> > package compatible with gentoo. Some people may consider downstream pc
> > files more dangerous because reverse deps are affected. But really, if
> > there is no other alternative, we shouldn't be treating this as a
> > special case. We patch upstream packages all the time after all
> 
> Exactly. I don't understand why this is an issue at all. Obviously,
> if upstream does not ship a .pc file or ships a broken one, we try
> to work with upstream to get it fixed on their end. If they are
> uncooperative, we fix it on our end.

Adding a pkgconfig file is a bit of a special case. Some distros have a
habit of renaming and creating .pc files for various libraries. But in
Gentoo, almost all pkgconfig files come from upstream with minimal
modification. So a .pc file that is specific to Gentoo is a rare
exception, and it could cause confusion for users who installed Gentoo
on their development machine and who wish to develop new portable
software.

Of course, in the case of Lua, it seems that all other distros are
already providing .pc files, so joining them would seem to be the
correct thing to do (we would simply be recognizing a de facto
standard).

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Markos Chandras]

On 05/10/2014 07:31 AM, Alexandre Rostovtsev wrote:
> On Sat, 2014-05-10 at 13:50 +0800, Ben de Groot wrote:
>> On 10 May 2014 04:34, Markos Chandras <hwoarang@gentoo.org> wrote:
>>> On 05/09/2014 09:32 PM, Tom Wijsman wrote:
>>>> On Fri, 9 May 2014 16:15:58 -0400
>>>> Rich Freeman <rich0@gentoo.org> wrote:
>>>>
>>>>> I think fixing upstream is a no-brainer.
>>>>
>>>> It indeed is, this is the goal; you can force them in multiple ways,
>>>> some of which can be found on the Lua bug and previous discussion(s).
>>>>
>>>>> The controversy only exists when upstream refuses to cooperate (which
>>>>> seems to be the case when we're one of six distros patching it).  If
>>>>> there are other situations where we supply our own files please speak
>>>>> up.
>>>>
>>>> Not that I know of; the refusal to cooperate is what this is all about,
>>>> see my last response to hwoarang before this mail for a short summary.
>>>> Though, I think that the Lua maintainers can explain all the details...
>>>>
>>>>> When the only issue is maintainer laziness I could see fixing that in
>>>>> a different way...
>>>>
>>>> It has always been an issue; we could always use more manpower, ...
>>>>
>>>> https://wiki.gentoo.org/wiki/Contributing_to_Gentoo
>>>>
>>>
>>> Well to me it feels that gentoo specific .pc files is a similar problem
>>> to any other patch that affects upstream code in order to make the
>>> package compatible with gentoo. Some people may consider downstream pc
>>> files more dangerous because reverse deps are affected. But really, if
>>> there is no other alternative, we shouldn't be treating this as a
>>> special case. We patch upstream packages all the time after all
>>
>> Exactly. I don't understand why this is an issue at all. Obviously,
>> if upstream does not ship a .pc file or ships a broken one, we try
>> to work with upstream to get it fixed on their end. If they are
>> uncooperative, we fix it on our end.
> 
> Adding a pkgconfig file is a bit of a special case. Some distros have a
> habit of renaming and creating .pc files for various libraries.

Isn't this the same thing? If Debian creates/renames upstream pc files,
and you use Debian as a development box, you have the same problem:
Develop software which is not portable across distros.

I have done very limited upstream development myself, but my opinion has
always been that upstream developers who use
Debian/Gentoo/Fedora/$FOOlinux as their dev environment shouldn't care
about distro peculiarities. That's packagers' job, who are responsible
to make the upstream software compatible with each distribution.

 But in
> Gentoo, almost all pkgconfig files come from upstream with minimal
> modification. So a .pc file that is specific to Gentoo is a rare
> exception, and it could cause confusion for users who installed Gentoo
> on their development machine and who wish to develop new portable
> software.

I don't see how this is a bad thing. This actually makes us look good in
the sense that we stick to upstream code as much as possible.

In an ideal world, all distros would be compatible :)


-- 
Regards,
Markos Chandras

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

[Samuli Suominen]

On 10/05/14 12:39, Markos Chandras wrote:
> On 05/10/2014 07:31 AM, Alexandre Rostovtsev wrote:
>> On Sat, 2014-05-10 at 13:50 +0800, Ben de Groot wrote:
>>> On 10 May 2014 04:34, Markos Chandras <hwoarang@gentoo.org> wrote:
>>>> On 05/09/2014 09:32 PM, Tom Wijsman wrote:
>>>>> On Fri, 9 May 2014 16:15:58 -0400
>>>>> Rich Freeman <rich0@gentoo.org> wrote:
>>>>>
>>>>>> I think fixing upstream is a no-brainer.
>>>>> It indeed is, this is the goal; you can force them in multiple ways,
>>>>> some of which can be found on the Lua bug and previous discussion(s).
>>>>>
>>>>>> The controversy only exists when upstream refuses to cooperate (which
>>>>>> seems to be the case when we're one of six distros patching it).  If
>>>>>> there are other situations where we supply our own files please speak
>>>>>> up.
>>>>> Not that I know of; the refusal to cooperate is what this is all about,
>>>>> see my last response to hwoarang before this mail for a short summary.
>>>>> Though, I think that the Lua maintainers can explain all the details...
>>>>>
>>>>>> When the only issue is maintainer laziness I could see fixing that in
>>>>>> a different way...
>>>>> It has always been an issue; we could always use more manpower, ...
>>>>>
>>>>> https://wiki.gentoo.org/wiki/Contributing_to_Gentoo
>>>>>
>>>> Well to me it feels that gentoo specific .pc files is a similar problem
>>>> to any other patch that affects upstream code in order to make the
>>>> package compatible with gentoo. Some people may consider downstream pc
>>>> files more dangerous because reverse deps are affected. But really, if
>>>> there is no other alternative, we shouldn't be treating this as a
>>>> special case. We patch upstream packages all the time after all
>>> Exactly. I don't understand why this is an issue at all. Obviously,
>>> if upstream does not ship a .pc file or ships a broken one, we try
>>> to work with upstream to get it fixed on their end. If they are
>>> uncooperative, we fix it on our end.
>> Adding a pkgconfig file is a bit of a special case. Some distros have a
>> habit of renaming and creating .pc files for various libraries.
> Isn't this the same thing? If Debian creates/renames upstream pc files,
> and you use Debian as a development box, you have the same problem:
> Develop software which is not portable across distros.

Say, a package XYZ makes use of xyz.pc and it's distribution specific,
then you switch to a distribution that also ships XYZ but without
pkg-config file,
you can simply...

export FOOBAR_LIBS="-lfoo"
export FOOBAR_CFLAGS="-I/usr/include/foo"
./configure
make
make install

...as pkg-config allows using it without the .pc files by design. This
is an non-issue.

- Samuli

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

[hasufell]

Rich Freeman:
> On Fri, May 9, 2014 at 4:08 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
>> On Fri, 09 May 2014 20:57:29 +0100
>> Markos Chandras <hwoarang@gentoo.org> wrote:
>>
>>> I was wondering, is there a good reason we keep our own pkgconfig
>>> files instead of communicating that to upstream and resolve that
>>> properly?
>>
>> Yes, when your "instead of ..." is not an option.
>>
>>> What other distributions do? Or are we a special case and
>>> we need our own pc files?
>>
>> No, see https://bugs.gentoo.org/show_bug.cgi?id=509392#c23 which reads:
>>
>>     "You do realize that out of five distros (Fedora, Debian,
>>     Slackware, SuSe, Mandriva) I checked five ship a .pc file?" by mabi.
> 
> I think fixing upstream is a no-brainer.  The controversy only exists
> when upstream refuses to cooperate (which seems to be the case when
> we're one of six distros patching it).  If there are other situations
> where we supply our own files please speak up.
> 
> When the only issue is maintainer laziness I could see fixing that in
> a different way...
> 

The fact is... missing pkg-config files are in 99% of the cases all
fixable by fixing the build systems of packages that assume those
pkg-config files... more specific: provide a fallback (I gave enough
links for that in the reponse to the council agenda mail).

This improves portability overall, for upstream, for us, for other
distros and for random users.

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

[hasufell]

Markos Chandras:
> On 05/09/2014 09:32 PM, Tom Wijsman wrote:
>> On Fri, 9 May 2014 16:15:58 -0400
>> Rich Freeman <rich0@gentoo.org> wrote:
>>
>>> I think fixing upstream is a no-brainer.
>>
>> It indeed is, this is the goal; you can force them in multiple ways,
>> some of which can be found on the Lua bug and previous discussion(s).
>>
>>> The controversy only exists when upstream refuses to cooperate (which
>>> seems to be the case when we're one of six distros patching it).  If
>>> there are other situations where we supply our own files please speak
>>> up.
>>
>> Not that I know of; the refusal to cooperate is what this is all about,
>> see my last response to hwoarang before this mail for a short summary.
>> Though, I think that the Lua maintainers can explain all the details...
>>
>>> When the only issue is maintainer laziness I could see fixing that in
>>> a different way...
>>
>> It has always been an issue; we could always use more manpower, ...
>>
>> https://wiki.gentoo.org/wiki/Contributing_to_Gentoo
>>
> 
> Well to me it feels that gentoo specific .pc files is a similar problem
> to any other patch that affects upstream code in order to make the
> package compatible with gentoo. Some people may consider downstream pc
> files more dangerous because reverse deps are affected. But really, if
> there is no other alternative, we shouldn't be treating this as a
> special case. We patch upstream packages all the time after all
> 

I don't agree with that. Pkg-config files are like headers and library
files. They affect code of developers.

If I mess with random configure.ac files in ffmpeg... it doesn't really
affect any1 other than gentoo users in 99% of the cases.

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

[hasufell]

Markos Chandras:
>> Gentoo, almost all pkgconfig files come from upstream with minimal
>> modification. So a .pc file that is specific to Gentoo is a rare
>> exception, and it could cause confusion for users who installed Gentoo
>> on their development machine and who wish to develop new portable
>> software.
> 
> I don't see how this is a bad thing. This actually makes us look good in
> the sense that we stick to upstream code as much as possible.
> 
> In an ideal world, all distros would be compatible :)
> 

Yeah, I was actually under the impression that gentoo is a
"meta-distribution" and therefor takes the pain to maintain a complex
Package Manager Specification amongst other things.

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.

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

[Rich Freeman]

On Sat, May 10, 2014 at 9:00 AM, hasufell <hasufell@gentoo.org> 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

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

[hasufell]

Rich Freeman:
> On Sat, May 10, 2014 at 9:00 AM, hasufell <hasufell@gentoo.org> 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?

Gentoo in general as a _development platform_. I'v also seen people
arguing "this library isn't used by any package, let's remove it". Not.
A. Reason.

> 
> 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.
> 

The impact is on users as well if they try to build software with a
broken build system.

> 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 are effectively spreading the philosophy of modifying interfaces,
libraries, headers and other things that are not trivial (and with one
of the pkgconfig file additions in lua... we also got a library rename
that breaks dlopen. So this is just the first step.).
This has at first almost no effect on others, but for us, get's a lot of
"shit" done.
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.


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

As described above, it is definitely worse.

TBH, I don't want to be part of a "get shit done" distro. I could simply
switch to debian then and do all the funny "lolpatches".

I was hoping that QA is the authority that separates "get bugs fixed"
from "get shit done".

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

[Rich Freeman]

On Sat, May 10, 2014 at 9:36 AM, hasufell <hasufell@gentoo.org> 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?

If we say we stick to upstream then we don't provide pkg-config files
at all (in these cases).  Then when Debian does the other upstreams
use them and then those packages break on Gentoo.  People are still
going to target their favorite distro no matter what we do.

The only people with the power to break the distro-targeting behavior
are the maintainers of the upstream packages.  The linux kernel
maintains a few stable branches with well-defined support periods, and
as a result you can bet that just about any distro is going to be on
one of them.  Few other projects take this kind of care.  Indeed, some
upstreams can't be bothered to change their SONAME when their ABI
changes.

You could try to get distros to come together, but that tends not to
work either.  The minor distros all have lots of incentive to do this,
but nobody cares about targeting them.  The really big distros don't
have incentive to play along, because they can just tell everybody
that if their software breaks on their distro it is their problem.
Then you have companies like RedHat which want to differentiate
themselves so the last thing they want is to make other distros as
robust, and to be fair they don't want to do the integration work only
to have others mooch.

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 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.

Rich

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

[hasufell]

Sure, this is a more complex problem.

My point is, for pkg-config files it is relatively easy to fix stuff
that depends on non-standard files (I can write a devmanual section
about that, but err... this is really trivial). The amount of these
downstream pkg-config files is not as big as you might think (yet). So
just saying "no" to all new downstream additions will not cause a big
explosion and thousands of packages failing to build. Look at the
tracker, it's just a few we know of. Cmake is mostly not affected,
autotools is often complex enough to still find the libs, Makefiles need
a one-line patch. And, by the time we discover more, we can work towards
removing them.

It will raise awareness about this problem and about the fact that
distros like debian tend to do it the lazy way.
So it is a pretty easy way to improve portability across distros and so on.

We shouldn't do things wrong just because they didn't blow up in our
face yet.

I am confused why this gets so much attention. The additional workload
is really minor. So, not allowing this makes sense to me.
For exotic exceptions and corner cases, we can still bend the rules.
But, "debian does it too" is not one.

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

[Peter Stuge]

Rich Freeman wrote:
> > Longterm, this makes it year after year more difficult to develop
> > software for "Linux".
> 
> I'm with you here, but what is the solution?
> 
> If we say we stick to upstream then we don't provide pkg-config files
> at all (in these cases).

I think this is a sane default.


> Then when Debian does the other upstreams use them and then those
> packages break on Gentoo.

I like Gentoo to stay very close to upstream.

If upstream pkg A depends on $distro-specific foo of pkg B then that
will obviously not work in an environment only following upstreams,
and will require effort to untie gentoo pkg A from $distro specifics.

As has been said, that's ultimately a portability problem of A, which
becomes the maintainer's problem when creating gentoo pkg A.

This will mean that some unportable upstreams cannot be packaged for
Gentoo without fixing their bugs first. If they don't consider this a
bug then they are making a bad decision and sadly the Gentoo
maintainer sortof has to live with that. :\

I don't think it's fair to force a Gentoo maintainer to do any
specific thing here. If a Gentoo maintainer is willing to untie
unhelpful upstreams from their own bugs for the benefit of Gentoo
then that's fantastic, even if upstreams don't understand so.

But I don't think it's reasonable to *require* from Gentoo maintainers.

If I were looking at a bug which asks to create an ebuild from an
upstream which has a $distro-specific bugtie then I might as well
close it as WONTFIX as long as the upstream don't fix their problem.

But I would equally welcome anyone else to reopen the Gentoo bug if
they had untied the bugtie.


//Peter

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

[Samuli Suominen]

On 12/05/14 20:47, Peter Stuge wrote:
> Rich Freeman wrote:
>>> Longterm, this makes it year after year more difficult to develop
>>> software for "Linux".
>> I'm with you here, but what is the solution?
>>
>> If we say we stick to upstream then we don't provide pkg-config files
>> at all (in these cases).
> I think this is a sane default.

Except having pkg-config is the only way to fix some of the build issues
we are seeing
today, like getting 'Libs.private: ' for static linking, there has been
multiple bugs lately,
and we are in middle of process of obsoleting every custom foo-config
due to same
reasons, so having pkg-config files is an absolute requirement.
Some binary-only distros might get away without them, but we won't.

>
>
>> Then when Debian does the other upstreams use them and then those
>> packages break on Gentoo.
> I like Gentoo to stay very close to upstream.
>
> If upstream pkg A depends on $distro-specific foo of pkg B then that
> will obviously not work in an environment only following upstreams,
> and will require effort to untie gentoo pkg A from $distro specifics.

pkg-config by design works without .pc files if needed, by exporting
FOO_LIBS
and FOO_CFLAGS, so if this is the only problem with them, it's really no
problem
at all compared to the problems caused by lacking the pkg-config files


(Are we seriously discussing banning something useful as pkg-config
files?! That's retarded. Must be some joke.)

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]

Dnia 2014-05-12, o godz. 21:24:26
Samuli Suominen <ssuominen@gentoo.org> napisał(a):

> On 12/05/14 20:47, Peter Stuge wrote:
> > Rich Freeman wrote:  
> >>> Longterm, this makes it year after year more difficult to develop
> >>> software for "Linux".  
> >> I'm with you here, but what is the solution?
> >>
> >> If we say we stick to upstream then we don't provide pkg-config files
> >> at all (in these cases).  
> > I think this is a sane default.  
> 
> Except having pkg-config is the only way to fix some of the build issues
> we are seeing
> today, like getting 'Libs.private: ' for static linking, there has been
> multiple bugs lately,
> and we are in middle of process of obsoleting every custom foo-config
> due to same
> reasons, so having pkg-config files is an absolute requirement.
> Some binary-only distros might get away without them, but we won't.

Err, you can disallow static linking. Simple solution with extra
advantages like improving security.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

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

[Peter Stuge]

Samuli Suominen wrote:
> >> If we say we stick to upstream then we don't provide pkg-config files
> >> at all (in these cases).
> 
> > I think this is a sane default.
> 
> Except having pkg-config is the only way to fix some of the build
> issues we are seeing today, like getting 'Libs.private: ' for
> static linking, there has been multiple bugs lately,

I honestly don't think that it's Gentoo's place to fix those issues.

Just error out. Make users complain to upstream when upstream has a
problem. Don't hide the problem and amass a huge support workload.


> and we are in middle of process of obsoleting every custom foo-config

Again I don't think that's Gentoo's decision to make. It could
certainly be a user's decision, but complexity would explode.


> so having pkg-config files is an absolute requirement.

You haven't provided a rationale, only a circular argument:

"We're taking action which requires .pc so having .pc is a requirement."

My key point is that it isn't Gentoo's responsibility or duty to fix
problems introduced by upstreams, even if Gentoo developers are so
skilled that they would be able to.

I think your time is better spent on things that are not broken.


> Some binary-only distros might get away without them, but we won't.

I think it's perfectly fine to refuse including something that is
broken and unmaintainable. That doesn't mean that one has to be an
asshole about it and treat requsts badly however. It's easy to
politely decline. "This is too much effort for me to maintain.
Please become a developer and maintain it if you want it, or proxy
maintain it."


> > If upstream pkg A depends on $distro-specific foo of pkg B then that
> > will obviously not work in an environment only following upstreams,
> > and will require effort to untie gentoo pkg A from $distro specifics.
> 
> pkg-config by design works without .pc files if needed,
> so if this is the only problem with them, it's really no problem

I think it is a problem, because Gentoo starts having an opinion.

I don't like that. For me, Gentoo is all about letting me decide.

That means I must be exposed to broken upstreams, so that *I* can
decide how to deal with them.

Maybe introduce a USE flag for installing .pc:s in ${FILESDIR} ?


> at all compared to the problems caused by lacking the pkg-config files

Don't own those problems - they aren't yours.


> (Are we seriously discussing banning something useful as pkg-config
> files?! That's retarded. Must be some joke.)

I don't think I said to ban them. I said that I want Gentoo to stay
close to upstream by default. I also said that maintainers shouldn't
be expected to untie upstream bugknots.

Please do not call me retarded again.


Thanks

//Peter

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

[Alon Bar-Lev]

On Mon, May 12, 2014 at 9:48 PM, Peter Stuge <peter@stuge.se> wrote:
> Samuli Suominen wrote:
>> >> If we say we stick to upstream then we don't provide pkg-config files
>> >> at all (in these cases).
>>
>> > I think this is a sane default.
>>
>> Except having pkg-config is the only way to fix some of the build
>> issues we are seeing today, like getting 'Libs.private: ' for
>> static linking, there has been multiple bugs lately,
>
> I honestly don't think that it's Gentoo's place to fix those issues.
>
> Just error out. Make users complain to upstream when upstream has a
> problem. Don't hide the problem and amass a huge support workload.
>

From my experience, there are lots of issues in upstream projects'
build system, most of the these result from lack of knowledge. Up
until now, downstream patches that were actually used by users found
their way better into upstream than just complaining that stuff
breaks, as upstream honestly does not have the knowledge to fix. It
also gives a chance to test them properly before submitting.

There are projects that will not accept any patch regardless of the
problem it solves, unless it is for their own favour distribution and
packager, so not providing solution for our users does not makes sense
to me.

Regards,
Alon

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

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 4134 bytes --]

On Mon, 12 May 2014 20:48:16 +0200
Peter Stuge <peter@stuge.se> wrote:

> Samuli Suominen wrote:
> > Except having pkg-config is the only way to fix some of the build
> > issues we are seeing today, like getting 'Libs.private: ' for
> > static linking, there has been multiple bugs lately,  
>
> I honestly don't think that it's Gentoo's place to fix those issues.
> 
> Just error out. Make users complain to upstream when upstream has a
> problem. Don't hide the problem and amass a huge support workload.

"But it works fine on distro Y!" ... "Oh, you don't fix it; I go
to distro Y, I don't want to wait for upstream to support Gentoo."

But true, besides a temporary fix downstream it should go upstream; I
just don't think that it is something which we want to force our users
to do. It is more of an expectation that the maintainer should do this;
if not, users that are interested can help out with that as well.

> > and we are in middle of process of obsoleting every custom
> > foo-config
> 
> Again I don't think that's Gentoo's decision to make. It could
> certainly be a user's decision, but complexity would explode.

Yeah, I'm not sure how well that would work for java-config for
instance; it helps a lot, I can't make myself a picture of a world
without java-config. It would introduce regressions with no benefit. 

> > so having pkg-config files is an absolute requirement.
> 
> You haven't provided a rationale, only a circular argument:
> 
> "We're taking action which requires .pc so having .pc is a
> requirement."

"We made a highway for driving with requires a car so having a car is a
requirement to drive on the highway." Now try driving an airplane on it.

In other words; it is easy to use what it has been made for, it gets
harder if you are trying to differ from the purpose of it.
 
> My key point is that it isn't Gentoo's responsibility or duty to fix
> problems introduced by upstreams, even if Gentoo developers are so
> skilled that they would be able to.
> 
> I think your time is better spent on things that are not broken.

If we all did that, I wonder how much would still work; not as much as
we have achieved now, so I like that we've made an "added value".

> > > If upstream pkg A depends on $distro-specific foo of pkg B then
> > > that will obviously not work in an environment only following
> > > upstreams, and will require effort to untie gentoo pkg A from
> > > $distro specifics.
> > 
> > pkg-config by design works without .pc files if needed,
> > so if this is the only problem with them, it's really no problem
> 
> I think it is a problem, because Gentoo starts having an opinion.
> 
> I don't like that. For me, Gentoo is all about letting me decide.

+1 but that doesn't withhold that there are defaults here and there.

> That means I must be exposed to broken upstreams, so that *I* can
> decide how to deal with them.

Yeah, you could switch to a distro where it all works, or keep running
away from them; but isn't a fix instead what you really want, I think
you can easily configure Gentoo to not apply any patches as all (disable
src_prepare) but you get to keep the pieces given all the breakage.
 
> Maybe introduce a USE flag for installing .pc:s in ${FILESDIR} ?

We have recently decided to not use an USE flag for small files; so,
I'm not sure if this proposal is much different from that decision.

You can use INSTALL_MASK for this purpose I think.

> > (Are we seriously discussing banning something useful as pkg-config
> > files?! That's retarded. Must be some joke.)
> 
> I don't think I said to ban them. I said that I want Gentoo to stay
> close to upstream by default. I also said that maintainers shouldn't
> be expected to untie upstream bugknots.
> 
> Please do not call me retarded again.

That might have been meant to be about the thread as a whole.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Peter Stuge]

[-- Attachment #1: Type: text/plain, Size: 1883 bytes --]

Tom Wijsman wrote:
> besides a temporary fix downstream it should go upstream;

I think there is agreement that this is the ideal, and that the
discussion is about what to do when that seems out of reach.


> > My key point is that it isn't Gentoo's responsibility or duty to fix
> > problems introduced by upstreams, even if Gentoo developers are so
> > skilled that they would be able to.
> > 
> > I think your time is better spent on things that are not broken.
> 
> If we all did that, I wonder how much would still work; not as much as
> we have achieved now, so I like that we've made an "added value".

Don't get me wrong - I'm wholeheartedly in favor of contributing
fixes upstream, but not of building a support workload when upstream
is uncooperative.


> > Maybe introduce a USE flag for installing .pc:s in ${FILESDIR} ?
> 
> We have recently decided to not use an USE flag for small files; so,
> I'm not sure if this proposal is much different from that decision.

Oh ok. Sure.


> You can use INSTALL_MASK for this purpose I think.

Mh but that'll also kill .pc files from upstream. The option I'd like
is to mask only the ones added by Gentoo. I would be fine with them
having gentoo- names. That makes it very clear that this interface is
a Gentoo-specific thing. However, that throws off the autoconf
pkg-config macros. :\


> > > (Are we seriously discussing banning something useful as pkg-config
> > > files?! That's retarded. Must be some joke.)
> > 
> > I don't think I said to ban them. I said that I want Gentoo to stay
> > close to upstream by default. I also said that maintainers shouldn't
> > be expected to untie upstream bugknots.
> > 
> > Please do not call me retarded again.
> 
> That might have been meant to be about the thread as a whole.

All right, fair enough there too.


Thanks

//Peter

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

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

[Samuli Suominen]

On 12/05/14 22:25, Peter Stuge wrote:
>>>> (Are we seriously discussing banning something useful as pkg-config
>>>> files?! That's retarded. Must be some joke.)
>>> I don't think I said to ban them. I said that I want Gentoo to stay
>>> close to upstream by default. I also said that maintainers shouldn't
>>> be expected to untie upstream bugknots.
>>>
>>> Please do not call me retarded again.
>> That might have been meant to be about the thread as a whole.
> All right, fair enough there too.
>
>
> Thanks
>
> //Peter

Sorry, yes, I meant the thread as a whole of course.

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

[Markos Chandras]

On 05/12/2014 06:47 PM, Peter Stuge wrote:
> Rich Freeman wrote:
>>> Longterm, this makes it year after year more difficult to develop
>>> software for "Linux".
>>
>> I'm with you here, but what is the solution?
>>
>> If we say we stick to upstream then we don't provide pkg-config files
>> at all (in these cases).
> 
> I think this is a sane default.
> 
> 
>> Then when Debian does the other upstreams use them and then those
>> packages break on Gentoo.
> 
> I like Gentoo to stay very close to upstream.

Gentoo should be close to upstream as much as possible and developers
are actively encouraged during recruitment sessions to always try to
upstream their patches. If you think a maintainer deviated from upstream
for no good reason, well, I would like to think this is an exception
instead of common practice.

-- 
Regards,
Markos Chandras

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

[hasufell]

Samuli Suominen:
> 
> On 12/05/14 20:47, Peter Stuge wrote:
>> Rich Freeman wrote:
>>>> Longterm, this makes it year after year more difficult to develop
>>>> software for "Linux".
>>> I'm with you here, but what is the solution?
>>>
>>> If we say we stick to upstream then we don't provide pkg-config files
>>> at all (in these cases).
>> I think this is a sane default.
> 
> Except having pkg-config is the only way to fix some of the build issues
> we are seeing
> today, like getting 'Libs.private: ' for static linking, there has been
> multiple bugs lately,
> and we are in middle of process of obsoleting every custom foo-config
> due to same
> reasons, so having pkg-config files is an absolute requirement.
> Some binary-only distros might get away without them, but we won't.
> 

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.

I feel it is time to make some more strict rules after seeing people
importing plain debian hacks, including renaming of libraries, renaming
of pkgconfig files and probably worse to come.

> 
> (Are we seriously discussing banning something useful as pkg-config
> files?! That's retarded. Must be some joke.)
> 

No, you are twisting words here.

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

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1942 bytes --]

On Mon, 12 May 2014 21:25:55 +0200
Peter Stuge <peter@stuge.se> wrote:

> Tom Wijsman wrote:
> > besides a temporary fix downstream it should go upstream;
> 
> I think there is agreement that this is the ideal, and that the
> discussion is about what to do when that seems out of reach.

Yes, I think that's the case too; I think I wrote it for completeness.

> > If we all did that, I wonder how much would still work; not as much
> > as we have achieved now, so I like that we've made an "added value".
> 
> Don't get me wrong - I'm wholeheartedly in favor of contributing
> fixes upstream, but not of building a support workload when upstream
> is uncooperative.

The "bug"load is there regardless of whether you want to support or it
or not when upstream is uncooperative; so, I think that the status quo
is currently that people whom can and want to fix it can do so.

But I don't think that forcing them to do or not do it is something
that the whole distribution can be convinced to do, at least from what
I read; I'm also not sure if you meant to suggest such force or not, ...

> > You can use INSTALL_MASK for this purpose I think.
> 
> Mh but that'll also kill .pc files from upstream. The option I'd like
> is to mask only the ones added by Gentoo. I would be fine with them
> having gentoo- names. That makes it very clear that this interface is
> a Gentoo-specific thing. However, that throws off the autoconf
> pkg-config macros. :\

Yeah, it's tricky; this makes me think, can't we perhaps install them
in a separate directory that pkg-config could check?

That way, we don't need to change the name anymore; and they would
still be separate, allowing you to separately mask them.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1124 bytes --]

On Mon, 12 May 2014 23:43:34 +0200
Tom Wijsman <TomWij@gentoo.org> wrote:

> Yeah, it's tricky; this makes me think, can't we perhaps install them
> in a separate directory that pkg-config could check?

A quick collective brainstorm on IRC gives the idea that this is not
worth the effort, as this imposes patching multiple packages, as well as
migrating the deferring packages to it; for the sake of introducing
INSTALL_MASK supported breakage, where one could grep for the packages
that install .pc files and add the more specific paths to INSTALL_MASK.

Another idea that came up is to only have this separate directory be
read by the ebuild environment, such that it doesn't affect users that
are developers and mistakenly use the .pc files in their own program;
but such support would introduce overcomplex behavior in the ebuild
environment of Portage, which is already enough complex as it is.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

[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 ;-)

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

[hasufell]

It's called keeping status quo.