I don't see a reason not to preload it. Let's add it to comps.

Or alternatively, add it as a weak dependency to g-o-a.

The only thing it brings in in addition are the evolution and the libmspack packages. All the other dependencies it needs are already required by something else (these two dependencies can bring in its own additional dependencies, like highlight and cmark).

I would suggest removing evolution as dependency of evolution-ews, if possible.

Putting evolution in the base install would be contrary to Fedora's deliberate decision to not have an email client in the base install of Fedora Workstation. Evolution wouldn't be the best candidate for that anyway, for a couple of reasons probably not relevant here.

Evolution does more than Mail ;)

The Evolution is needed to build the evolution-ews, after all, the evolution-ews is a plugin/module for the Evolution (and for the evolution-data-server).

Nonetheless, it would be possible to split the relevant parts into a separate package in the Fedora. I do not know, maybe evolution-ews-core or some such name (no idea what the usual practices are here), which the evolution-ews package would Require and which would contain only bits, which do not need the Evolution. Unless such split would be confusing for the users, of course.

Putting evolution in the base install would be contrary to Fedora's deliberate decision to not have an email client in the base install of Fedora Workstation.

I think it'd perfectly fine to revisit this decision. I've always considered it table stakes to include a desktop email client. Pretty much all of our contemporaries and competition do.

Sure, but including some email client vs. including Evolution specifically are two very different proposals. We probably don't need to debate that here. For the purposes of this issue, it seems clear enough that we won't include evolution-ews if it requires Evolution. If the dependency can be split, then we can include the subpackage that doesn't depend on Evolution.

Evolution does more than Mail ;)

Correct, but some of the other features of evolution (the package and the GUI app, not the other components provided by evolution-data-center) are already provided by other GNOME Core Apps such as GNOME Calendar and GNOME Contacts.

The Evolution is needed to build the evolution-ews, after all, the evolution-ews is a plugin/module for the Evolution (and for the evolution-data-server).

I understand how evolution would require evolution-ews, it's unfortunate if the reciprocal also needs to be valid. After all, evolution-data-server (installed by default on Workstation and Silverblue) can "live" without evolution too.

Nonetheless, it would be possible to split the relevant parts into a separate package in the Fedora. [...] Unless such split would be confusing for the users, of course.

In my opinion regular users will hardly notice the split, given that this is neither a GUI app, nor a CLI tool or a service that users are actively utilizing. It's more confusing now, if I may say: I ended up filing an issue with GNOME against G-O-A, only to be informed by the maintainer that evolution-ews was the missing piece.

Right, it is sort of confusing. There are runtime dependencies (not like build time dependencies), that make the things work. Like with the GOA, it does not do much, it only offers account definitions to anyone asking for it. It's the evolution-data-server, which can use this information and create from it a real definition of a Calendar, Address Book, Task List, Memo List and Mail account. These definitions can be used by other parts connecting to the evolution-data-server, like the evolution-calendar-factory takes care of the Calendar, Task List and Memo List definitions and the evolution-addressbook-factory of the Address Book definitions - these factories are built-in in the evolution-data-server. The evolution reads (and uses) the Mail definitions, but it also understands all the other parts, by connecting to the respective factory processes. Not everything is builtin, thus some account types (like the Microsoft 365) require additional plugins to be installed, which can read these account definitions provided by the evolution-data-server and make from them everything it can do.

For the split on the packaging level, I do not mind myself, but I also do not want to make the decision both whether to do it and how to call the new package. I can provide suggestions, share my opinion, but that's the most. I do not know usual practices, nor the rules, thus my opinion can be wrong. That's why I need someone else to decide, correct and guide me.

Nonetheless, it would be possible to split the relevant parts into a separate package in the Fedora. I do not know, maybe evolution-ews-core or some such name (no idea what the usual practices are here), which the evolution-ews package would Require and which would contain only bits, which do not need the Evolution. Unless such split would be confusing for the users, of course.

This sounds like the right idea. I wonder, what goes into the subpackage and what remains in the main package? I see the evolution-ews package installs a bunch of shared libraries; do only some of those depend on the Evolution GUI program.

evolution-ews-core sounds like a good name for the subpackage.

Okay.

I would make evolution-ews to install the evolution bits and the coresubpackage, thus when the users call dnf install evolution-ews, they get everything as before. The core subpackage could be installed on its own (bringing in also evolution-ews-langpacks). The main package would contain only bits which require the Evolution. The subpackage would contain everything else.

the evolution-ews package installs a bunch of shared libraries; do only some of those depend on the Evolution GUI program.

Yes, only some of them depend on the evolution. If I'm not mistaken, it's only these two:
/usr/lib64/evolution/modules/module-ews-configuration.so
/usr/lib64/evolution/modules/module-microsoft365-configuration.so

I will verify that later, if this is the green to "implement" the package split.

OK, this sounds like a good plan.

The Working Group discussed this at today's meeting and we're fine with including the bits that don't depend on Evolution itself.

Here you are:
https://src.fedoraproject.org/rpms/evolution-ews/c/aa4ad28fba98623895e9237386c623f93d3ecc50?branch=rawhide
https://koji.fedoraproject.org/koji/taskinfo?taskID=127699616

Uninstalling evolution-ews does not uninstall evolution-ews-core, which is one difference I noticed. I do not know whether it's possible to change it anyhow, without bringing in the Evolution. Otherwise it seems to do what I'd expect from it. There was also needed a change in the code, which I already committed in the upstream and which will be part of the 3.55.2 release. I added that change into the Fedora until the release is done.

Note, just in case, installing evolution-ews-core will also bring in the evolution-ews-langpacks.

So now we just need to decide how exactly to pull in evolution-ews-core. One option would be to use a conditional weak dependency in gnome-contacts and gnome-calendar:

Recommends: (evolution-ews-core if gnome-online-accounts)

Maybe that's too complicated, though. We could just do Recommends: evolution-ews-core instead. It could even possibly go in the gnome-online-accounts package itself, although it's probably better to put the dependency in the apps that actually want it.

I think it would be appropriate to have gnome-online-accounts Requires: evolution-ews-core. GOA shows Microsoft 365; therefore, it should be expected to work.

Definitely should be attached as a dependency for gnome-online-accounts

Is there any information about this task? Should we expect changes in Fedora Silverblue 42?

Please, remember to add the package to the next Fedora release. It is being missed on Fedora 42. It works as intended.

This change is approved for Fedora 43.

It could either be Recommends: evolution-ews-core from gnome-online-accounts, or it could be added directly to comps.