Re: gentoo package management requires portage-utils package

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

_______________________________________________
Bug-cfengine mailing list
[email protected]
https://cfengine.org/mailman/listinfo/bug-cfengine