Class reportExcessBuildRequires
source code
action.Action --+
|
action.RecipeAction --+
|
policy.BasePolicy --+
|
policy.Policy --+
|
reportExcessBuildRequires
NAME
====
B{C{r.reportExcessBuildRequires()}} - suggest items to remove from C{buildRequires} list
SYNOPSIS
========
- C{r.reportExcessBuildRequires('required:component')}
- C{r.reportExcessBuildRequires(['list:of', 'required:components'])}
DESCRIPTION
===========
The C{r.reportExcessBuildRequires()} policy is used to report
together all suggestions for possible items to remove from the
C{buildRequires} list.
The suggestions provided by this policy are build requirements
listed in the recipe's C{buildRequires} list for which Conary
has not specifically discovered a need. Build requirement
discovery is not perfect, which means that even though this
policy prints a warning that a build requirement might not be
necessary, Conary does not know that it is definitely not needed.
These are only hints. If you are not sure whether a component
should be removed from the C{buildRequires} list, it is safer
to leave it in the list. This is because an extra component
in the C{buildRequires} list is very unlikely to cause trouble,
but a truly missing component causes failure (by definition).
Because dependencies on C{:runtime} components are the least
likely dependencies to be discovered automatically, this policy
currently does not recommend removing any C{:runtime} components.
EXAMPLES
========
This policy is normally called only internally by other Conary
policies. However, a recipe can report build requirements
that are known by the recipe maintainer to be required but
which Conary does not discover automatically by passing a
list of these components. For example, if this policy
says that C{foo:devel} and C{blah:perl} are possible extra
build requirements, but you know that they are required in
order to correctly build the included software, you can
turn off the warnings like this:
C{r.reportExcessBuildRequires(['foo:devel', 'blah:perl'])}
This will tell the C{reportExcessBuildRequires} policy that
C{foo:devel} and C{blah:perl} are known to be required to
build the package.
No regular expressions are honored.
|
|
|
|
|
updateArgs(self,
*args,
**keywords)
The default way to update a class is to override any provided
keywords. |
source code
|
|
|
|
|
|
|
|
|
|
| _reportExcessSuperclassBuildRequires(self,
reqList) |
source code
|
|
|
Inherited from policy.Policy:
compileFilters,
doProcess,
filterExpArgs,
filterExpression,
mtimeChanged,
policyException,
policyInclusion,
walkDir
Inherited from policy.BasePolicy:
dbg,
error,
info,
postInit,
postPolicy,
warn
Inherited from action.RecipeAction:
doAction,
doPrep,
doSuggestAutoBuildReqs,
init_error
Inherited from action.Action:
addArgs
|
|
|
bucket = 64
|
|
|
processUnmodified = True
allows special handling for derived packages in order to make only
appropriate changes in the derived package.
|
|
|
filetree = 0
where to look for files to which to apply the policy:
policy.DESTDIR, the default, walks the files in the
destdir, policy.BUILDDIR walks the files in
the build directory, and policy.PACKAGE iterates over
the packaged files rather than walking the destdir, which besides
being possibly faster also applies to files that are not on the
filesystem (like device nodes).
|
|
Inherited from policy.Policy:
invariantexceptions,
invariantinclusions,
invariantsubtrees,
keywords,
recursive,
rootdir
Inherited from policy.BasePolicy:
allowUnusedFilters
|
|
The default way to update a class is to override any provided
keywords. Subclasses which have the ability to provide more intelligent
handling can override this method. This method is invoked automatically
by recipe.py when a recipe references a policy object. It acts rather
like __init__ except that it can meaningfully be called more than once
for an object.
Some keyword arguments (at least exceptions and
subtrees) should be appended rather than replaced.
- Overrides:
policy.BasePolicy.updateArgs
- (inherited documentation)
|