[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dpkg-gencontrol breakage?



This one time, at band camp, Stephen Gran said:
> This one time, at band camp, Goswin von Brederlow said:
> > Stephen Gran <sgran@debian.org> writes:
> > 
> > > Hello all,
> > > 
> > > I'm seeing this in a package I'm an uploader for:
> > > 
> > > dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
> > > dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
> > > dpkg-gencontrol: warning: unknown substitution variable ${F:Version}
> > > 
> > > These are, to my knowledge, legitimate fields, no?  Is this known
> > > breakage?  I looked at the bug reports for debhelper and dpkg, and I
> > > don't see anything about this - am I just looking in the wrong place?
> > 
> > Afaik that happens when there are unset, e.g. no libs to depend on
> > whrere found.
> 
> Weeeell, I think that would be a bug - it should pass a null string,
> rather than something unparseable, and I remember it used to.  This
> looks to me like it actually has problems parsing the string - 'unknown
> substitution variable' doesn't imply an unset variable, but a variable
> name that is undefined.
> 
> Also, ${F:Version} should be expanded to the Version string from the 
> package named, and so should never be unset, right?
> 
> Ah, it looks like this may be the change:
> dpkg (1.10.14) unstable; urgency=low
> 
>   * controllib.pl:
>     * Rewrote the parsedep stuff, so that it wasn't done during control
>       file parsing.  Scripts that need the internal parsed format should
>       call parsedep on the field's value.
>     * Split the substvars parsing into a separate function.
>     * No longer validate dependency fields when reading the control file.
>       Some fields may have vars in them, which breaks the validation.
>     * dpkg-gencontrol calls substvars after parsing the control file, and
>       then validates the substituted depends lines.  Originally,
>       substitution occured only during writing of the final output file.
> 
> Have to go look at the actual source and file a bug, I guess.  I have a
> hard time believing nobody's seen this before now, though.

To answer my own question, it looks like the parsing field is broken.
This is the code from :

if (defined($substvar{$vn})) {
            $v= $lhs.$substvar{$vn}.$rhs;
            $count++;
        } else {
            &warn("unknown substitution variable \${$vn}");
            $v= $lhs.$rhs;
        }
It doesn't need to warn here, and it should return '' instead of
$lhs.$rhs - this is where the literal quoting of the variable name is
coming from, I think.  Maybe I'm wrong - I don't particularly know dpkg
internals.  This still doesn't explain why F:Version isn't getting
filled out, but I'll chase that down later.

Any one have any suggestions, or comments, besides the obvious 'file a
bug?'
-- 
 -----------------------------------------------------------------
|   ,''`.					     Stephen Gran |
|  : :' :					 sgran@debian.org |
|  `. `'			Debian user, admin, and developer |
|    `-					    http://www.debian.org |
 -----------------------------------------------------------------

Attachment: signature.asc
Description: Digital signature


Reply to: