A commonly occuring scenario is that a package patches the configure
script, but that the corresponding configure.in contains shell code that
is not portable. In cases like these, configure.in is typically not used
during the build, therefore there is no need to check it for portability.
This also applies to all other combinations where a file is patched and
the corresponding file.in contains unportable shell code.
Before, adding "Binary file matches" (including the quotes) to
CHECK_WRKREF_EXTRA_DIRS led to a syntax error. Adding this string is so
obvious that it should have been added a long time ago already.
These appear to have been cargo culted around for a while, don't even have
anything to do with DESTDIR mode, and are completely useless. Simplify the
logic a little while here. Noticed by rillig@.
When all files are skipped, the tool dependency is not added as well.
This allows packages to skip the check without defining the user-settable
variable CHECK_PERMS.
Since the portability checks are concerned about bashisms, it doesn't make
sense to apply them to programs that will later be run in bash anyway.
Suggested by gdt via private mail.
These files typically come with a corresponding Makefile.in file, and the
same portability issue is in the .in file as well. For building the
package it is only necessary to patch the .in file. Patching the .am file
as well would mean additional work for the pkgsrc package maintainer.
Nevertheless, such fixes should be reported upstream. The upstream
maintainer is more interested in a patch for Makefile.am, since the .in
file is only generated.
Suggested by wiz via private mail.
Before, file names that start or end with spaces were trimmed by read(1),
as specified by POSIX 2004 and POSIX 2018.
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/read.html
This edge case bug had been present since the very beginning of this
code, in November 2006.
Filenames containing backslashes or newlines are still not supported, and
probably never will be intentionally supported.
Up to now, these files had been skipped because they didn't start with a
#! line. Still, they contain shell programs, therefore it makes sense to
check them.
Since several years, the portability check only checks for shell files.
Instead of opening each extracted file to see whether it is a shell file,
it is more efficient to filter the files based on their names. This saves
a few system calls and in the case of lang/gcc9, half of the total
running time.
The file extensions to be excluded from the check have been sorted by
their count in the PLISTs. This data does not accurately represent the
source files of the package, but it's better than nothing.
Since pkgtools/check-portability is not installed by default, it will not
harm any existing pkgsrc setup. To activate it, it has to be installed
manually. After a testing phase, it will be installed whenever
PKG_DEVELOPER is set.
have a GNU_RELRO flag. (they won't because it doesn't do anything to them).
Should eliminate some of the need for CHECK_RELRO_SKIP, especially for some
Go binaries.
Skip any lines of otool output that do not start with a tab, ensuring we
only check valid files and ignore e.g. shell scripts. Older versions of
otool would simply print no output on such files, whereas newer releases
print "is not an object file".
This is only performed if PKG_DEVELOPER and RELRO are in use.
After a suggestion during my talk at BSDCan 2017; thanks!
Also, submitted on tech-pkg@ for review mid-June.
As a next step, it seems this can be extended to libraries, just like the
check for SHLIBS does (from which this is inspired).
Introduce Icon Theme cache handling framework
Icon Theme cache files are used by GTK+ and maintained with the
gtk-update-icon-cache tool. Each Icon Theme package duplicates
its own maintainance scripts: only the specified icon theme directory
differs. With this framework, if packages have ICON_THEMES=yes,
associated icon themes will be detected and their cache files will
be maintained automatically.
Change cache handling behaviour as follows:
* Icon theme caches will be updated if either gtk2+ or gtk3+
gtk-update-icon-cache tool is available.
* With installation of gtk2+ package, not only hicolor icon theme but
also any other icon theme cache files will be updated.
* Prevent removal of icon caches at deinstall, gtk3+ may be installed and
using them.
* Ditto with gtk3+, gtk2+ may not be installed now, so caches must be
maintained by gtk3+.
If ${_USE_NEW_PKGINSTALL} is "yes", then use the new "pkgtasks",
"init", and "pkgformat/pkg"-scripts frameworks instead of the
existing "pkginstall" framework.
Assert MAKE_DIRS_PERMS and OWN_DIRS_PERMS have the right number of
words before using a multivariable .for loop over those variables.
This prevents errors in parsing the makefiles.
than on all of the rpaths. We can't always exclude the rpath being added,
for example when the compiler adds its own behind our back, so this avoids
false positives.
