I think that problem is somewhere else and it is IMO fundamental problem. Everything hangs on one simple fact that master branch of the Fedora packages is used now to build packages from the other Fedora-based distributions. It would be b*dy easy remove all icons caches updates if other distributions would be following much faster absorbing at least some crucial packages changes which are affecting many other packages. I was not fully aware of this and I've personally hit this difficulty not on my proposal of the remove hicolor icon caches but on proposing, for example, OpenIPMI or readline changes. Most of my changes were by those packages maintainers simple discarded (readline 100% and in case OpenIPMI ~50%). I'm not trying to blame anyone here but all this only *result* of some assumptions that master branch must be fully compatible with more than one distribution or more than one distribution versions. I've been thinking about submitting shortly after finish hicolor theme caches updates other themes similar scriptles. After this, I've been planning - introduce remove glib modules registrations and desktop files caches updates - ask kalev to push texinfo changes which would allow removing ail scriptlets with install-info (https://bugzilla.redhat.com/show_bug.cgi?id=1482019) - as last (biggest) proposal already discussed here remove all ldconfig executions in %post/%postun To be honest I'm thinking to give up .. Why? Because all those backward compatibilities and compatibilities with other distributions make whole distribution maintenance de facto EXTREMELY difficult and only few people among active Fedora packages have a possibility to check the impact of own changes on other Fedora versions and other distros as well. Fedora packages git repos are in kind of brain split state. From one side I fully understand that some people are trying to kill up-to-date other distributions and from the other side few Fedora versions back packages needs to have instant update of many packages which are on the move. >From the other side the same git repos have per fedora main version separated branches so holding on master branch all %ifings which add some possibility to build new versions of the packages on older Fedora versions or even other distributions. Without clear decision about abandoning support of EPEL or older Fedoras on master branch difficulty of the Fedora maintenance will be growing with factorial of the other versions. A lot of valuable time of the packagers will be wasted as well and it will be the source of some constant frustrations. I can list few more things which will be necessary to maintain: - older Fedoras and other distributions have the completely different set of C, C++ and linker flags Fiddling around those flags and keep consistency across all Fedora versions and other distros sooner or later will blow up. Two months ago I've proposed add --as-needed to default linker options and it was discarded. Now I better understand why .. because the impact of this one line change mixed with all those other compatibilities maintained on master branches real DISASTER!!! And many people trying to keep all those incompatibilities will be simple *upset*. As an initiator of such changes without REALLY cleaning first all this mess will have only many enemies here :/ - ~week ago I've proposed during ldconfig scriptets discussion to consider abandoning regenerate using ldconfig ld.so.cache and use it by ld.so As long as looks even correct and I had some private conversation that many other people have been thinking about this way earlier than I still in the current state of the Fedora introduce such change now is clear that will be NEVER accepted! :-/ >From this point of view, it is possible to form the conclusion that Fedora as the distribution is in kind of soft crisis. As long as other distributions are using already for example --as-neeeded more than few years I think that it exactly this not written straight anywhere goal of keeping such compatibility is the main causes of leaking end users to other distributions. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
