Just for the record list of things which are now on crash course with EPEL/RHEL Fedora which are widely used in Fedora specs:
On EPEL/RHEL in spec must be present in spec:
- BuildRoot
- %clean
- %defattr() in %files
NO ONE adds now any %ifings around those parts of the specs (just please do not propose start doing this 😀)
Especially remove %defattr() breaks RHEL/EPEL compatibility causing that in case of many packages files no longer will be owned by root:root but by user on which package is built.
Then .. just behind the corner we have:
- dropping icons themes caches updates
- drop update desktop files cache
- drop update glib schema index
The number of specs are now having some %ifings or will need to add new %ifings:
- icons cache update
$ grep gtk-update-icon-cache * | awk -F\. '{print $1}' | uniq | wc -l
411
(it is not only about hiicolor theme
hicolor affects:
$ grep 'gtk-update-icon-cache' * | grep hicolor | awk -F\. '{print $1}' | uniq | wc -l
303
specs)
- desktop files cache updates:
$ grep update-desktop-database * | awk -F\. '{print $1}' | uniq | wc -l
290
- glib schema index updates
$ grep glib-compile-schemas * | awk -F\. '{print $1}' | uniq | wc -l
107
Not to mention that already in many spec files above has been removed without the care about RHEL/EPEL. In other words, EPEL/RHEL compatibility in case of many specs ALREADY gone!!!!
If someone will say that what is on the master branch is RHEL/EPEL compliant is is not even close to the REAL truth.
Things which we can do:
- remove all /sbin/ldconfig in %post/%postun
- remove all install-info single pages (de)registration and replace it by file triggers which regenerates /usr/share/info/dir out of all files in /usr/share/info/*info* files
BTW (de)registration of the single info files is not working now.
Why? Because if anyone will try to regenerate info dir file by regenerate this file out of *info* files suddenly will find that after this main index is way longer!!!
As well .. because if many packages with info pages are installed with --excludedoc some non-zero number of those installations will fail because this is not working.
in Fedora already general policy is to separate documentation into doc subpackage because it is ONLY WAY to deal with systems installations with not at all or limited documentation installed.
As result anaconda installer does not support in interactive mode system installation without documentation which in many cases makes sense.
Fixing info pages handling will open gates to remove all doc sub packages and integrate back all this stuff into proper packages.
Effectively this may cause significant reduction number of the packages.
All those things which are possible to remove/improve will need careful %ifings if anyone really wants to keep RHEL/EPEL compatibility.
The scale of the changes related to ldconfig will be even bigger because we are talking about:
$ grep /sbin/ldconfig * | awk -F\. '{print $1}' | uniq | wc -l
3080
packages. In case install-info simplifications it is:
$ grep install-info * | awk -F\. '{print $1}' | uniq | wc -l
289
specs.
If we really want to keep on master RHEL/EPEL compatibility EVERY such mass simplification effectively will cause DRAMATIC INCREASE IN THE COMPLEXITY of all affected specs!!!
Calling all those Fedora changes as "improvements" will be **100% LIE**.
IMO critical mass has been already reached even if for the very long time it was not a big deal.
And last argument.
If RHEL/EPEL compatibility is so valuable why no other distributions are trying to archive such goal to keep all possible specs in simplest possible form?
And yet another Linux kernel code analogy.
In the past many times I saw new device drivers source code written in the way which allowed compile kernel module on the wide range of kernel versions. Using some number of #ifdef it is quite easy.
However, on integration, such code with Linus branch, all this kind of code have been refused to ask to make module code clean first only for Linus master branch.
What was handy for kernel driver developer is UNACCEPTABLE on the scale whole kernel code. Why? One reason is obvious that in many cases it makes this code unreadable by average kernel developer however it is not the only issue.
Now kernel policy is that kernel code needs to be indented in an exact way making this code easy to read for everyone. Problem is that even indent tool trashes formatting of the C code if there is to many (especially many levels nested) #ifdefs.
Exactly the same issue is with Fedora specs. Specs with some critical number especially many times nested %ifings will be impossible to automatically format or effort on prepare such tool will be tenths times if not bigger than writing simple awk script which can do this if it will be no %ifings.
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
