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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
