-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Fri, 2018-01-19 at 16:37 +0000, Tomasz Kłoczko wrote: > 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. Well, it's been just 1-2 weeks since FPC removed those scriptlets from guidelines. And I removed it from every single package (almost). > 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. Well, I think because this is simply easy. If we separate changelog to other file / make it auto-generated, then it should be easier for people to maintain f26/f27/master branches separately. Right now, cherry-picking is never cleanly applies due to changelog. Well, we need to do something with Release field as well, I don't know why it is still not auto-generated... > 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 Better to send PR 😉 > To be honest I'm thinking to give up .. Don't 😉 > 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. I think real problem here is that people want same spec to build everywhere. And we are not able to teach people to not do this. Only way how we can teach them is to make it impossible (e.g. deny push if there are such %ifs or like that). > 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. Now mattdm will jump in with "Don't try to kill EPEL!!!". > 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! :-/ I learned something out of this -- don't propose multiple cleanups/improvements at the same time. People just mix them and have hard times to decide. Get one thing done, then another. > 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. I totally understand your frustration, I feel same. But we can make it better, it's just about talking to different people (e.g. FPC, FESCo, Council) to get some agreements and so on. If you are not happy with something, you should fix it and not just complain. - -- - -Igor Gnatenko -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpiJ6EACgkQaVcUvRu8 X0wi0A/+J9k2+/M0x3s72IwI6VGCEjWe+4jSE5MnbjcgsF6ywxF5whQOmG6mf/X0 zpBpiifsa8W+PvenTXR3Jet4aQwgEldqlD+nHowvjVkjT0f63/Cc5dmp+cYB/kPL n0Gy/Vii1BjFavKxAOU7+wGKmpzaj2yf+z1FZv4JFBhdcw82AtjD/zku8WCqyhYr ZUH0o5W7zMxGKkLAI0N74ruJ51qjtyODaXksYu3PKRg1wg3Ew9v4Rx/f1x2GdTUL CgzzNbHw0tUOffxzV75S9CkisUGdiMU2IxFUep7K5921tsOhkGsbcJgklxMor6xi ap/Rw3/HdJcrPGlXOXF10IEE7Q6ah1D4pqn/Z7viY+yeGv6drJwXknwD0aw9PiIw MljDYepNI0Z8cN1s2O0UbmeRVdPZ+/9oGVoNAYN2YxfLoaVXwnPDSkqaMsVur+B9 xy09Na/OwZA5CxeyBLwcHu+IX/JePhr+51xasJ73/WofYviazsbulIgKjioW1Xm9 BkOie1kgJHTBfRMdeRIr1JYUx/on4VQ3wumkLHy+b+z7VoK0r/6R9QPXyzVApDsD 9voUoj9iui7hC71Pr+HoYh7hG5KYIdkZkDM8+jffrOoBRFUV/Ce8U/zdNuZBFZOw ArVjLWiIfqzQcQ0zV3zDS0qxfXxcxavZbobDsqNajsT2/c6PaAg= =cNO5 -----END PGP SIGNATURE----- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
