On Mar 17, 2008, at 3:09 PM, Elliott A. Johnson wrote:
Hello,I've noticed when installing gentoo packages via cfengine that it requires binaries provided by the gentoo package app-portage/portage- utils.
The current package maintainer does know about this, I told him a couple months ago, it will be fixed at the next point release of cfengine, which is when he's waiting to update the portage package (due to other bugfixes and portage-related features only currently in trunk).
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:
[..]
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?
Yes.
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.
Odd, this doesn't seem to jive with the code. Here's the block:
--package.c--
/* Search for installed versions of package */
snprintf(VBUFF,CF_BUFSIZE,"/usr/bin/qlist -IevC %s",nameptr);
if ((pp = cfpopen(VBUFF, "r")) == NULL)
{
CfLog(cferror,"Could not execute the qlist command. Is portage-
utils installed?\n","");
return -1; } -------------But instead of seeing this error output, you're getting output from the cfpopen command itself, but it seems that cfpopen is not returning NULL like it should, even though the command opening failed. If it had, then an error code would have been sent back to do.c which would have skipped that package [1]. So the problem is likely not in the package code, but may be a problem in popen.c. I'll have some time to debug that next week.
By the way Jo, you mentioned how you didn't write the Portage code so you needed to push this off to me. I checked your FreeBSD code, it looks like you're returning 0 to the caller, which means that if pkg_info can't be called, it defaults to `no match' and will try to go ahead and install. This should probably be switched to -1 like the above code, as you yourself said it should return failure back to the package manager [1]. (Note, its not just FreeBSD code; looking into this most of the others, and even the default case for no package manager in PackageCheck all return 0. I'll try to write up a patch to address this.)
--package.c--snprintf (VBUFF, CF_BUFSIZE, "/usr/sbin/pkg_info -qE '%s%s%s'", pkgname, CMPSENSEOPERAND[cmp], version);
if ((pp = cfpopen (VBUFF, "r")) == NULL)
{
CfLog(cferror,"FATAL: Could not execute pkg_info.\n","popen");
return 0;
}
-------------
[1] Calling code:
----do.c-----
match = PackageCheck(ptr,name,ptr->pkgmgr, ptr->ver, ptr->cmp);
/* Check for a problem executing the command */
if ((match != 1) && (match != 0))
{
snprintf(OUTPUT,CF_BUFSIZE,"Error: Package manager query
failed, skipping %s\n", name);
CfLog(cferror,OUTPUT,"");
ptr->done = 'y';
continue;
}
------------
--
Eric Searcy
OSU Open Source Lab
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ Bug-cfengine mailing list [email protected] https://cfengine.org/mailman/listinfo/bug-cfengine
