boost: patch serialization sources

[ericriff]

Specify library name and version: boost/1.74.0

There are some missing includes on boost.serialization 1.74 which makes some projects fail to build.
The first patch comes from this commit boostorg/serialization@f72b9fc

The second one comes from this one boostorg/serialization@8acf329

• I've read the guidelines for contributing.
• I've followed the PEP8 style guides for Python code in the recipes.
• I've used the latest Conan client version.
• I've tried at least one configuration locally with the
  conan-center hook activated.

[ghost]

I detected other pull requests that are modifying boost/all recipe:

• [boost] b2 user-config.jam needs CXX binary to be quoted as path may contain spaces #4149
• Boost/1.72.0/mpi #3959

This message is automatically generated by https://github.com/ericLemanissier/conan-center-conflicting-prs so don't hesitate to report issues/improvements there.

[conan-center-bot]

All green in build 1 (fc810683dd46a6596b1b77278f29ea668abdef8f)! 😊

• boost/1.69.0: Generated 131 packages. All logs here
• boost/1.70.0: Generated 131 packages. All logs here
• boost/1.71.0: Generated 131 packages. All logs here
• boost/1.72.0: Generated 131 packages. All logs here
• boost/1.73.0: Generated 131 packages. All logs here
• boost/1.74.0: Generated 131 packages. All logs here

[prince-chrismc]

Since these are included in 1.75, would it not be better to wait for that?

#3903

[uilianries]

Since these are included in 1.75, would it not be better to wait for that?

#3903

Same question, 1.75.0 is already available.

[ericriff]

We need this for our project. We have our internal mirror so it is not a big deal if we don't merge it. But since I had to fix this anyways I decided to open a PR to share it with the community. It is up to you if you want this or not. I think it has some value since bumping boost versions in big projects is not straightforward. Developers having trouble moving to 1.75 may be benefited by having a fully functional 1.74 package.

…

On Mon, Dec 21, 2020, 17:31 Uilian Ries ***@***.***> wrote: Since these are included in 1.75, would it not be better to wait for that? #3903 <#3903> Same question, 1.75.0 is already available. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3918 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANVXYZIYWDZQY3KNS557Y4LSV6WA3ANCNFSM4U6GDWOA> .

[prince-chrismc]

Please check out the draft policy about patches and with a little more support this topic will be unblocked =)

[ericriff]

OK so under the new guidelines this patches would fall into the source patches since it is cherry picking some commits from future versions. I didn't check if this commits are in 1.75 but I'm sure that at least one of them is should be there.

Should I decline this PR then? As I said, we are using our own internal mirror so I don't really mind it. This was just me sharing my fixes to the package, but I understand the reasoning behind the guidelines.

**Source patches.-** ConanCenter DOES NOT accept patches **backporting bugfixes or 
features** from upcoming releases, they break the principle of minimum surprise, 
they change the behavior of the library and it will no longer match the 
documentation or the changelog originally delivered by the authors.

[prince-chrismc]

Yes, thats my understanding as well.

But to clear my intention is not to discourage you but to encourage you to share your thoughts =)

[ericriff]

So I understand where you are coming from with the new guidelines for patches. It sounds great to have the packages to be as vanilla and close to the developer intentions as possible. This is great to make conan and its packages a drop-in replacemente for whatever you where using before to handle your project's dependencies.
These new policies are great to prevent a snow ball effect of having more and more patches retro fitting features and fixes and ending up with a package that is very different from what you get by building it from sources yourself.
Regardless, I think we could have some exceptions in place for cases like this one where it is a small change to fix a package which is otherwise non-functional in some scenarios and doesn't change the libraries behavior in any way. In this case we're just adding some headers here and there.
It makes even more sense with boost, which is a monster of a package and it is hard to migrate big projects that depend on it from one version to another.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This pull request has been automatically closed because it has not had recent activity. Thank you for your contributions.