Here's a list of known modules that could cause problems in Carmel, with or without workarounds. If you want to report a module that's not in this list, please open a new issue.
Generated with .pm.PL
Some modules are generated by .pm.PL execution in configure, and META.json doesn't contain provides fields. This makes Menlo fail to record the correct version number from the generated .pm files. carmel install would fail when verifying the build artifacts to be valid, since there's no version information available.
Proc::PID::File::Fcntl #71
There're some other modules that caused a similar issue in the past with Carton: https://github.com/perl-carton/carton/issues/210 Most of them have been dealt with by fixing the metadata in the upstream.
Extra code triggered during make/Build
Some modules generate files during the make install execution, which Carmel doesn't run. carmel install succeeds, but you'll get a runtime error with carmel exec.
XML::SAX #22
XS modules that are not relocatable
Some XS module with external C library dependencies record the installation path and does not work when relocated to a new directory. carmel install succeeds, but you'll get a loading error with carmel exec.
Alien::TidyHTML5 #61
Invalid provides in install metadata
Time::Piece::MySQL #89
Invalid NAME in Makefile.PL and install metadata
Some modules have invalid NAME field in Makefile.PL and that causes invalid package recorded in install.json data generated by Menlo. Carmel would give you a warning when you run carmel update, when there's such a module in your dependencies. There's no actual harm with this issue other than a warning noise in the output.
Here's a list of known modules that could cause problems in Carmel, with or without workarounds. If you want to report a module that's not in this list, please open a new issue.
Generated with .pm.PL
Some modules are generated by .pm.PL execution in configure, and META.json doesn't contain
providesfields. This makes Menlo fail to record the correct version number from the generated .pm files.carmel installwould fail when verifying the build artifacts to be valid, since there's no version information available.There're some other modules that caused a similar issue in the past with Carton: https://github.com/perl-carton/carton/issues/210 Most of them have been dealt with by fixing the metadata in the upstream.
Extra code triggered during make/Build
Some modules generate files during the
make installexecution, which Carmel doesn't run.carmel installsucceeds, but you'll get a runtime error withcarmel exec.XS modules that are not relocatable
Some XS module with external C library dependencies record the installation path and does not work when relocated to a new directory.
carmel installsucceeds, but you'll get a loading error withcarmel exec.Invalid
providesin install metadataInvalid NAME in Makefile.PL and install metadata
Some modules have invalid
NAMEfield inMakefile.PLand that causes invalid package recorded ininstall.jsondata generated by Menlo. Carmel would give you a warning when you runcarmel update, when there's such a module in your dependencies. There's no actual harm with this issue other than a warning noise in the output.