Le vendredi 16 novembre 2018 à 13:02 -0800, Japheth Cleaver a écrit : > > I'm not sure why punting like this is a good thing. RPM is a > standard, > moving along at what one might expect a core component to do, but to > the > extent that "evolving our packaging" means doing things at odds with > or > in an incompatible way other distros (whether downstream, > "downstream", or not) this is not a feature, or very nice. I think you do not realise how much old rpm is holding us back, and how much we limit ourselves in Fedora, and make ourselves more work, just to cater to those old rpm limitations. A small number of people, that include Jason Tibbitts, perform unappreciated heroic wonders all year round to limit the damage old rpm deficiencies inflict on Fedora and EPEL, and if you think the situation is imperfect, well it would be terrible without them. Really, if there is one distro component we should backport to el and all release streams, that's rpm + all Fedora macro packages, not the kernel. Classical rpm targets and works well for C/C++ projects that use autotools, a static small list of dependencies, and release as an archive. A growing part of the distribution does not fit this model any more. git and the internet blew away any limit on the number and cadence of dependencies for every language, including C/C++. Non C/C++ languages do not fit in the C/C++ macro model. Those new parts needs the same level of rpm support as previous projects, which means writing new macros, that build on other new macros, and it all falls appart if you can not rely on some of those other macros existing because of a time- jump in el land. Classical rpm macro argument processing is severely deficient, not even on par with shell getopts-level of argument processing, let alone the argparse-level many languages now sport. That creates a huge impedance mismatch with modern commands that expect more elaborate argument syntax. You can not drive them from rpm macros, you end up putting lists of arguments in variables to pass them to commands behind the macro argument parser. That should be fixed. Classical rpm has all kinds of weird warts to accommodate what people though would be the way to the future in the 90’s. Even though they created a brilliant design (mostly), they were far from omniscient or always right (and much too influenced by perl). After 20 years, living in the real future, it should not be iconoclastic to revisit some of their decisions. Most notably, all the dead-stupid %setup/%sources/Tag processing, that you know any rpm novice will misunderstand and get wrong, even before you attempt explanations. Those warts were merely annoying when dealing with a few thousands of distro packages, they have a real cost now the distro has grown. And so on. There's no reason rpm can not adapt to another decade of newness. But it needs to adapt. EL6 (or 7) rpm is not up to the task as is. All the project people that say distro packaging sucks loads, are not dead wrong. They're too prideful to put forward the thousand of rpm papercuts that made them look for something else, real men (and women) do not complain about papercuts, but those papercuts exist beneath the showy bogus arguments they usually put forward. Regards, -- Nicolas Mailhot _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
