erp5_catalog: Change order in which we update Bussiness Template

Required as most of the changes we have are in erp5_core and that's
why its important to install/update it before we install erp5_catalog_storage
bt5.

product/ERP5Type/tests/ERP5TypeTestCase.py

@@ -849,8 +849,8 @@ class ERP5TypeCommandLineTestCase(ERP5TypeTestCaseMixin):
       update_business_templates = os.environ.get('update_business_templates') is not None
       erp5_load_data_fs = int(os.environ.get('erp5_load_data_fs', 0))
       if update_business_templates and erp5_load_data_fs:
-        template_list[:0] = (erp5_catalog_storage, 'erp5_property_sheets',
-                             'erp5_core', 'erp5_xhtml_style')
+        template_list[:0] = ('erp5_property_sheets', 'erp5_core',
+                             erp5_catalog_storage, 'erp5_xhtml_style')
 
       # keep a mapping type info name -> property sheet list, to remove them in
       # tear down.

[Vincent Pelletier]

Commit message does not make sense to me: BT install order should follow dependencies more than "we do more changes in X than in Y".

[Ayush Tiwari]

Yes, I'll update the commit message, but if the change agreeable ? as anyways, this follows the dependency rule as erp5_core is dependent on erp5_catalog_storage and erp5_property_sheets.

[Vincent Pelletier]

The way I understand the change, it violates one dependency then: erp5_property_sheets is installed first (fine), then erp5_core (missing dependency: erp5_catalog_storage). The missing dependency is only fixed on the next install step.

Whether catalog or property sheets are installed first, I think we do not care (or if we do care, then one need to depend on the other), so it is not the issue for me here.

If we have two business templates with depend (de facto) on one another, then they should be merged in a single business template. If you can find a way to keep core and catalog separate it would be nice. But I believe merging them should be acceptable if it solves such bootstrap issues, as I think the only existing alternative catalog BT is the long-bitrot, never-used-in-production and very likely long-broken erp5_mysql_ndb_catalog.

If you do merge them, please check how existing sites will upgrade as the catalog document instance has some properties which must not be lost in the upgrade (security uid mapping, there may be more).

[Ayush Tiwari]

I think than instead of merging them into one and inviting more problems with upgrade, its better to solve this issue by just moving template items(portal_type Catalog, etc) concerning erp5_mysql_innodb_catalog from erp5_core to the aforementioned. This way erp5_mysql_innodb_catalog stays as a complete bootstrap for catalog storage all on its own, without having any dependency on erp5_core.