On 24 January 2018 at 11:21, Tomasz Kłoczko <kloczko.tom...@gmail.com>
wrote:
[..]
> Fact that those libraries are listed in:
>
> Libs.private: -lz -llzma -lm
>
> does not mean that some devel packages are needed. Libs.private is
> used on STATIC linking!!! Use static linking in Fedora is highly
> REDUCED
> So far I did not found even single source code build frameworks
> querying for Libs.private.
> *ALL* of them are asking for "libs".
Because above I'm not sure is it not will be good add to
/usr/lib/rpm/pkgconfigdeps.sh remove Libs.private from .pc files.
Second widely spread "mistake" related to .pc files is adding to devel
"Requires: pkgconfig"
[tkloczko@domek SPECS.fedora]$ egrep '^Requires:.*pkgconfig' * | wc -l
909
This is WRONG by one FUNDAMENTAL fact that pkgconfigdeps.sh script adds
such dependency AUTOMATICALLY!!
Fragment from this script:
---
-R|--requires)
while read filename ; do
case "${filename}" in
*.pc)
i="`expr $i + 1`"
[ $i -eq 1 ] && echo "$pkgconfig"
<<<<<<< here
---
----
BTW: second thing about this script is that first line suggests that it is
bash script when in reality it is PURE POSIX SH sript.
There are TONS of such scripts in Fedora.
----
back to pkgconfig Require
$ sudo dnf -C repoquery --whatrequires pkgconfig | wc -l
1379
So which one approach is wrong? which one is correct?
Before I point on right solution everyone who will be trying to follow my
way of analyse above myst add two additional conditions/facts:
- provide by devel pakage .pc file does not mean that such package as
isolated object requires pkgconfig
- there is only small fraction of the devel packages which may need
"Require: pkgconfig" because inside those devel packages are some shell
scripts like <foo>-config script or some m4 macros which are using pkgconf
command from pkgconfig package
So .. what is the answer?
Surprise .. BOTH approaches are WRONG:
BOTH facts should not used as input condition to add manually or
automatically "Requires: pkgconfg" becuse provide m4 macros or <foo>-config
scrip does not mean that when "BuildRequires: <foo>-devel"will be used in
other packages build procedure any .pc file or pkgconfig command.
Am I right???
So there are two possible solutions:
- if in some spec is used "Build-Requires: <foo>-devel" definitelly
MANUALLY should be added:
BuildRequires: pkgconfig
- when is used "BuildRequires: pkgconfig(<foo>)" it SHOULD or MAY be
treated that during build process pkgconfig will be used.
So easiest way t deal with this will be as well add to such spec:
BuildRequires: pkgconfig
*If* some will find a way how to add indirect "BuildRequires: pkgconfig"
when "BuildRequires: pkgconfig(<foo>)" is used.
Only in this case we are talking about ~2.3k in all {<arch>,noarch}.rpm
packages .. BECAUSE (again) pkgconfig should be ONLY used in BuildRequires.
OK .. this is easy to fix (two sed regex + two lines correction
in pkgconfigdeps.sh) -> send all affected packages to the furnace ..
BTW: because above exact chain of logical steps ALL "Requires: pkgconfig"
lines should be removed despite existing rhel/el6/el7/epel %ifings.
Please do not ask anyone I'm right or not (look on: "communal mistakes" )
.. just try to verify above using only and pure LOGIC.
If someone will not crush/disprove above in next few days someone should
take necessary action to remove all those line.
RHEL on next EL6/EL7 update should clean this as well because it will
slightly reduce dependencies between installed rpm packages written in rpm
database.
(kill me) OK .. some kind of bottom small dump of what is bouncing in my
head.
On top of those corrections minimizing only packages dependencies on which
I've been focusing in my free time in last few days I have few other
possible classes of problems.
Are you red alread on your face? OK so ..
After what was done/formed as idea to do mostly by me in PLD many thing and
changing/correcting/fixing using mass changes in mean time probably now
could be added few times more (again .. only related to dependencies).
OK .. II'll only check are you still able to sense pain ;-)
Yes .. we are talking about maybe even +100 possible mass changes.
Now .. if you sill feel the pain I'll try to spread it among other people ..
I cannot do this alone because:
- each such proposal of Mass Change Request will need each time:
- careful review (because some details or generally whole proposal may be
wrong) ... more eyeballs than better
- at the end such MCR at least one proven packager will be necessary to
shoot-and-forger at the and such MCR if it will pass whole peer review
process.
- someone will need to correct/update/add something in FPG or even
rpmlint (something else?)
- all packagers will be forced learn new things
- I have no proven packager privs and I'm not sure is it still not to early
give me such privs (or give me such privs at all)
Probably many people will be not happy/upset reading about so HUGE possible
of mass changes which may completely (en mass) they beloved specs files.
I'm afraid or almost sure that I'll make A LOT of enemies here because I'm
sure that most of those possibilities no one was able to spot .. or as
result other people will have some time allocated (co)working on those
cleanups/changes.
In soft scenario at least some people looking on some my email soon will
start at least making shark eyes/whispering "oh no .. not again!! >:-# "
Because I'm not a masochist .. and +halt of my career I've spend working
under sometimes restricted change control ..
Q: how to make such "pain" low as possible in case of Fedora where many
people don't know what it is change control? Or other not obvious (to
everyone) reasons.
I'm really opened on all suggestions.
This question really needs to be answered first before even I'll try first
time load my "machine gun" without even touching the trigger.
All those possible changes may introduce a lot of good things to Fedora but
I'm fully aware that time to time (hopefully not to often) something may go
wrong even after detailed peer review.
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
