On Thursday, 14 January 2021 12:03:32 AM AEDT David Prévot wrote: > That allowed you to discover an actual upstream oversight: both files > are (bit to bit) identical. You can safely add > --exclude /usr/share/civicrm/CRM/Grant/Export/Form/Map.php > to you phpab call. That file redefines CRM_Pledge_Export_Form_Map (it > even pretends that “[t]his class gets the name of the file to upload”), > and report it upstream. Please, do report it upstream.
Thanks for your comments. Reported as https://lab.civicrm.org/dev/core/-/issues/2298 > I suppose > CRM_Grant_Export_Form_Map is never used (yet it is mentioned in > CRM/Grant/Task.php) but detecting such issue at build time instead of > waiting for something bad to happen at runtime seems definitively worth > the effort. Makes sense, thanks. > About vendoring, I notice you bundle components that are actually > available as Debian packages (e.g., symfony). I wonder which one will > actually be loaded if packages offering the same classes you’re > vendoring are installed. Vendored version should be loaded first. Bundled Symfony is a historical issue since when I was maintaining CiviCRM in backports where Symfony was too old. These days I have not yet made up my mind whether I will be supporting build for backports but I want to keep my options open in case of incompatibility with newer releases, etc. Also I fear run-time errors due to Symfony version difference. I may have seen some issues before... > I noticed your following comment: > //Incompatible with Symfony Component(s) 4+: > yet ~4.4 is explicitly allowed composer.json (but I agree that 3.4.40 is > shipped according to composer.lock), did you dig up the actual problem? Most certainly an outdated comment from earlier releases. Compatibility with Symfony 4.4 is a relatively new feature. I'll have another look. > Security issues are found in PHP code all the time, given how poorly > maintained some packages are (either upstream or downstream), exposing > them all to your users is definitely something you want to avoid IMHO. Understood. I'll think about it. Perhaps there can be a good balance between vendored and system components determined on case-by-case basis... Anyway, perhaps it might be an easy task for you to get rid of Composer but for me it is very difficult. As I've mentioned in my previous email, both "CRM/Core/ClassLoader.php" and "CRM/Extension/ClassLoader.php" explicitly call Composer so the following error is thrown: ~~~~ Fatal error: CRM_Extension_ClassLoader::register(): The script tried to execute a method or access a property of an incomplete object. Please ensure that the class definition "Composer\Autoload\ClassLoader" of the object you are trying to operate on was loaded _before_ unserialize() gets called or provide an autoloader to load the class definition in /usr/share/civicrm/CRM/Extension/ClassLoader.php on line 74 ~~~~ That might require not-so-trivial patching that is beyond my level of expertise. -- Cheers, Dmitry Smirnov GPG key : 4096R/52B6BBD953968D1B --- "A closer look at U.S. deaths due to COVID-19" 2020-11-26, The Johns Hopkins News-Letter -- https://notthebee.com/article/a-few-days-ago-johns-hopkins-published-a-study-saying-corona-is-nbd-they-then-deleted-it-read-it-here-in-its-entirety -- https://web.archive.org/web/20201126223119/https://www.jhunewsletter.com/article/2020/11/a-closer-look-at-u-s-deaths-due-to-covid-19
signature.asc
Description: This is a digitally signed message part.
