app-emulation/bochs/bochs-2.4.1.ebuild: Unquoted Variable on line: 38 app-emulation/bochs/bochs-2.4.5.ebuild: Unquoted Variable on line: 38 Line 38: sed -i \ -e "s:\$(WGET) \$(DLXLINUX_TAR_URL):cp ${DISTDIR}/dlxlinux4.tar.gz .:" \ Makefile.in || \ die "sed Makefile.in failed" app-arch/unrar/unrar-5.1.5.ebuild: Unquoted Variable on line: 27 Line 27: sed_args+=( -e "s:-shared:-dynamiclib -install_name ${EPREFIX}/usr/$(get_libdir)/libunrar$(get_libname ${PV%.*.*}):" ) Obviously this is properly quoted. Many more examples like this.
Portage ebuilds are another one. Realistically, I don't want to keep adding to an already poor code base. Repoman is in serious need of a major re-factor and decent code structure. Since I'm nearing the end of the plugin-sync changes, I've started contemplating repoman and a good extensible system for it. I haven't ruled out using the plugin system for it too. Basically each module would be capable of doing a type of test or tests, not the list of the tests to do. If a new test type is needed, just create and add the new module. No fuss messing with the cli. I also want to have a configuration file(s) for types of checks. These configuration file(s) could easily be edited to add/remove/modify tests for the specific tests to do. ie. Under "unquoted variables" could be an exceptions list, easily edited by devs without the need for code changes or a new release. These list(s) could be made available on api.gentoo.org and automatically checked/updated on use. I am also considering detaching the repoman releases from the portage code base, although it would remain a part of the portage repo.
Another one in app-laptop/hdapsd-20141024: DOC_CONTENTS=" ${PN} requires a kernel module to function properly... "
(In reply to Patrick Lauer from comment #0) > app-emulation/bochs/bochs-2.4.1.ebuild: Unquoted Variable on line: 38 > app-emulation/bochs/bochs-2.4.5.ebuild: Unquoted Variable on line: 38 > > Line 38: > sed -i \ > -e "s:\$(WGET) \$(DLXLINUX_TAR_URL):cp > ${DISTDIR}/dlxlinux4.tar.gz .:" \ > Makefile.in || \ > die "sed Makefile.in failed" > > app-arch/unrar/unrar-5.1.5.ebuild: Unquoted Variable on line: 27 > > Line 27: > sed_args+=( -e "s:-shared:-dynamiclib -install_name > ${EPREFIX}/usr/$(get_libdir)/libunrar$(get_libname ${PV%.*.*}):" ) > > Obviously this is properly quoted. Many more examples like this. The whole point of the quoting check is to handle paths that may contain whitespace. How are either of the above DISTDIR or EPREFIX usages safe for whitespace in paths?
Zac has patched the _here_doc re which has fixed the unqouted variable error for portage. My test runs of the entire tree have not produced any results of this anymore. This will be released in portage-2.2.28 This ebuild is no longer in the tree, so marking as resolved.