Re: Plan to remove libxml2-static

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 24 January 2018 at 11:21, Tomasz Kłoczko <kloczko.tomasz@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux