Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[docs] Add policy about patching #3951

Merged
merged 2 commits into from
Jul 11, 2022
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions docs/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,6 +8,7 @@
* User documentation
+ [Contributing to Conan Center Index](../CONTRIBUTING.md)
+ [Adding Packages to ConanCenter](how_to_add_packages.md)
+ [Policy about patching](policy_patching.md)
+ [Review Process](review_process.md)
+ [Packaging policy](packaging_policy.md)
+ [Supported platforms and configurations](supported_platforms_and_configurations.md)
Expand Down
37 changes: 37 additions & 0 deletions docs/policy_patching.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,37 @@
# Policy about patching

The main guideline in ConanCenter is to provide already compiled binaries
for a set of architectures in the least surprising way as possible, so Conan
can be plugged into existing projects trying to minimize the modifications
needed. Packages from Conan Center should fulfill the expectations of anyone
reading the changelog of the library, the documentation, or any statement by
the library maintainers.

**Build system patches.-** In order to add libraries into ConanCenter sometimes
it is necessary to apply patches so they can consume existing packages
for requirements and binaries can be generated. These patches are totally
needed for the purpose of ConanCenter and Conan keeps adding features trying
to minimize these changes.

**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.

However, ConanCenter DOES accept **working software patches**, these patches
are needed to generate the binaries for architectures not considered by
library maintainers, or to use some compilers or configurations. These patches
make it possible to generate binaries that cannot be generated otherwise, or
they can turn a crashing binary into a working software one (bugs, errors, or
faults are considered working software as long as they produce deterministic
results).

Patches to sources to add support to newer versions of dependencies are
considered feature patches and they are not allowed either. They can
Comment on lines +29 to +30
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🙊 broken by websocketpp to allow recent version of boost while maintainer was MIA

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Replies to Croydon #3951 (comment)

introduce new behaviors or bugs not considered when delivering the
library by maintainers. If a requirement is known not to work, the recipe
should raise a `ConanInvalidConfiguration` from the `validate()` method.
Copy link
Contributor

@SpaceIm SpaceIm Dec 18, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe wait for conan 1.32.0 in CI?

Also, why raise only in validate(), when we can raise before dependency graph resolution (saves from potential download of useless recipes)?
For me, the new method validate() is only for verifications based on informations unknown before dependency graph resolution (options values and versions of dependencies).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi! The final version of the requirements is only known after the graph is fully resolved. There can be overrides and diamonds, the final version is not known in the configure() method while Conan is building the graph. I agree this would only happen with version ranges and with a few modifications in the graph resolution algorithm (a challenge for Conan 2). Now it will raise a conflict or not depending on the order of the requirements listed in app:

image

I agree this is not a scenario in conan-center-index where the version of the requirements is hardcoded.


**Vulnerability patches.-** Patches published to CVE databases or declared as
vulnerabilities by the authors in non-mainstream libraries will be applied
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
vulnerabilities by the authors in non-mainstream libraries will be applied
vulnerabilities by the authors will be applied

These seems like an unnecessary addition

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Active projects will apply them (in a timely manner 🤞 ) so we should not need to handle that case. I am okay with the original text

to packages generated in Conan Center.