Hello, I've noticed when installing gentoo packages via cfengine that it requires binaries provided by the gentoo package app-portage/portage-utils.
I created an ebuild for cfengine version 2.2.3, which didn't take this into account and so I didn't have portage-utils installed. The cfengine behavior that I exposed by not installing the binaries I would consider undesirable. Here is an example: ********************************************************************* Main Tree Sched: packages pass 1 @ Mon Mar 17 15:18:53 2008 ********************************************************************* PortageCheckPackage(): Requested net-misc/cfengine eq 2.2.3 PortageCheckPackage(): Trying installed version cfengine:box1: Couldn't run /usr/bin/qlist PortagePackageCheck(): Result cfengine:box1: Couldn't run /usr/bin/qatom PortageCheckPackage(): Trying installed version cfengine:box1: execv: No such file or directory PortagePackageCheck(): Result cfengine:box1: Couldn't run /usr/bin/qatom Then later on: BuildCommandLine(): Adding package 'net-misc/cfengine' to the list. It seems that since it can't use the qlist & qatom binaries that it fails to compare the package versions. Instead of disregarding the package it continues with the idea that 'error' != 'cfengine-2.2.3' and reinstalls cfengine-2.2.3. Wouldn't the desired behavior be to backout of the installation of that package after it received an error result? In my case this was an error in package management, but what if in other cases the qlist or qatom binaries were unexecutable for some reason. This could mean that any packages configured to be at a certain version would be reinstalled or potentially worse upgraded. I thought I'd point it out here in case the issue hadn't yet been discovered or documented. Thanks, -Elliott Johnson _______________________________________________ Bug-cfengine mailing list [email protected] https://cfengine.org/mailman/listinfo/bug-cfengine
