On Fri, 09 May 2014 14:07:46 +0000 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 ask them to consider to allow gentoo-*.pc files as an exception. Totally having no pkg-config files is going to keep breakage around, which is the reason as to why they are currently added. Fixes to build systems aren't always that easy as could be claimed; if they were, this wouldn't even be a problem in the first place. > This was discussed a year ago or so on the ML [0] with agreement that > we need at least a policy to forbid it. There is no such agreement there to forbid it. > A tracker [1] was opened and a devmanual policy [2] introduced. Added by hasufell, without consensus; also, there is disagreement: ssuominen: "there should be no such policy, [...]" https://bugs.gentoo.org/show_bug.cgi?id=445130#c6 ssuominen: "I support the idea of shipping pkg-config files [...]" https://bugs.gentoo.org/show_bug.cgi?id=443786#c1 Most tracker bugs are not responded to; so, I don't even see how banning would fix or prevent these bugs from existing. > Recently, QA team has voted on their own pkg-config policy which seems > to even diverge from the devmanual policy. [3] It's somewhat similar, just with other wording; your wording contains "unavoidable fix" which is exactly the case with some of these bugs (eg. with upstreams like Lua and/or NVIDIA), we recommend upstreaming and thus the maintainer can take similar exceptions as yours to that. > Further, QA team is not helpful when dealing with these policy > violations and seems to not care much, saying it's not even within > their scope. [4] It is not a policy violation; the only one who can act on the bug given the situation is the maintainer, the only thing QA can say is to take this to the gentoo-dev ML and/or in extension what you have done now. In addition, we give some thoughts to consider; that's all we can do, until there's more awareness and discussion from the community. We look out for the best interest of *all* developers. (GLEP:48) > Reasons and actual breakages why this causes cross-distro problems can > be seen here: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694671 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715796 > https://github.com/gusnan/devilspie2/commit/8bbc2f64bc2115178d5e1de170c1c1882eaf2799 We can work together with other distributions to use the same .pc files; for a organized way, this can be done in a central repository. This removes the need to endless wait on upstreams that won't accept the .pc files; instead, it'll force them to accept it as multiple distributions start to use a central repository for their .pc files. > It seems some people even go further actually doing the same terrible > debian hackery... RENAMING libraries to make their idea of slotting > work [5]. > This can break programs that dlopen these libraries [6]. It will, until distributions work together to cooperate on .pc files. > This should also be banned, IMO and exceptions have to be discussed on > dev ML with the community, not just silently hacked up by the > maintainer. With what purpose? To verbally agree that we can't convince upstream? > These things affect more than just gentoo (and definitely other > developers as well). And when something affects somebody, you should talk to them; in other words, we need to talk to and work together with the other distributions and share .pc files with them so we no longer have the current breakage and/or extra time wasted to build system maintenance that breaks too. But for a start; naming them gentoo-*.pc can at least make it clear to developers that their program will only work on Gentoo, avoiding most of the problems that would affect other distributions. Consider to choose for consistency that scales and works in the future; not for build system regressions, not for extra maintenance work. TIA -- 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