This patch adds rpmtags for file signatures and their length, so they
can be stored in the package header.
Changelog:
- update rpmtag values (rebase error) - Mimi
- fix test case 0004 - Florian
- update rpmtag values again - Fin
[lkardos@redhat.com: tag numbers was changed in order not to conflict]
Signed-off-by: Lubos Kardos <lkardos@redhat.com>
It may contain colon separated lists of path snippets that are removed from the end of the file name when adding the file to the package. This allows creating sub packages containing conflicting files. The path snippets are processed left to right.
- This adds brutally simple utf-8 validation to spec parse & package
construction: all string-class tags in headers are checked regardless
of other tag semantics.
- Parse-time validation is optional via RPMSPEC_NOUTF8
flag, but package construction time is required as we want to
stomp RPMTAG_ENCODING to all packages that pass. What is always
optional is whether non-valid utf-8 strings fail the build, defaulting
to off (but distros probably want to enable it)
- Note we dont give a damn about the spec itself, only what ends up in
packages: strings can come from numerous other sources than spec
directly, and OTOH who cares if eg spec comments are non-utf?
- The basic concept is not without merit but what was implemented here
has been stuck in experimental state in middle of two sorta conflicting
goals for four years now, and world has moved onward in the meanwhile.
The sepolicy part is better handled in the new selinux plugin, and other
action business belongs to packages (in the form of some trigger-like
scripts or such) rather than rpm plugins.
- Deleted here, but the sepolicy plugin functionality still needs
merging into the new selinux plugin...
- RPMTAG_COLLECTIONS left in place but tagged unimplemented as per policy
to never actually remove tags
- During building of a package a dummy tag is added to the signature
header. This tag reserves some space for gpg signatures. So during
signing of the package the gpg signatures can be put in this reserved
space and it is not necessary to rewrite the whole package to make some
space for gpg signatures.
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
- While the vast majority of scriptlet interpreters only consist
of the interpreter name itself, they all can consist of arbitrary
number of extra arguments. Rpm itself doesn't really care whether
the tags are strings or string arrays but the scalar definition
causes the rest of arguments to be invisible from eg python.
Also having the type shown as string array hints at the proper
query format when accessing these (and rpm itself is doing it
wrong too in --scripts alias). Related to ticket #847.
- The current method that --requires and friends use is kinda
cumbersome and outputs extra whitespace for dependencies which
dont have flags+version attached. Adding extensions for this
is likely to be easier than teaching query formatting to
permit conditionalizing on current value instead of just tag existence.
- For a more consistent experience wrt all the state-awareness stuff,
this needs to be easily querifiable too.
- Also makes the tagnames kludgery from commit
cac8c38960 unnecessary
- RPMDBI_BASENAMES (ugh) returns all headers with matching filenames,
whether the files are actually installed or not, which can be
rather misleading when dealing with file dependencies. The new
RPMDBI_INSTFILENAMES only returns headers with matching filenames
whose state indicates they are actually present on the system.
- Add support for new "OrderWithRequires: foo" spec syntax
which has "if and only if foo is present in transaction, order
the transaction as if this package required foo" semantics.
While it looks, and in some ways is, a soft dependency, this
is not the same as recommends/suggests etc: those have unknown
depsolver policy dependent semantics attached to them, whereas
ordering hints have a clear definition and is only relevant for rpm
itself, depsolvers should not even look at the data.
- This allows packages to express correct ordering for optional
functionality, such as
%post
if [ -x %{_bindir}/register-component ]; then
%{_bindir}/register-component %{name}
fi
If the package containing %{_bindir}/register-component is included
in the same transaction, it makes sense to have it installed before the
package(s) that use it. But as it is fully optional, Requires would
not be appropriate. Using OrderWithRequires allows this to be expressed
without dragging in extraneous dependencies for optional functionality.
- This is a bad "API" for verification, it can't be controlled and
causes heavy IO where one would not expect it. Getting rid of it now
before anybody starts relying on it...
- Leaving :fstatus format extension alone however, it's at least harmless
and produces a more predictable output than :vflags extension so it
might be actually useful in scripts.
- Now that our indexes are actually hardwired in the code we can
properly separate rpmtag vs db index names.
- Defined similarly to rpmTags, with rpmDbiTag being the "true enum"
and rpmDbiTagVal the integral type they present. As many of the
indexes are defined via RPMTAG values (and need to remain that
way to avoid breaking every single API user) we need to have a
compatible type with rpmTags.
- These would logically belong to rpmdb.h but keeping in rpmtag.h
to have them available "everywhere", we can't go including rpmdb.h
from rpmtag.h so keeping them here avoids potential unnecessary breakage.
- Another step to clean up the enum braindamage...
- rpmTag values are the only values that will be found, but it doesn't
mean the values passed are rpmTag enum members - eg anything from
a header is not. rpmTagGetValue() does come close to returning true
enums, but there's RPMDBI_PACKAGES and then RPMTAG_NOT_FOUND, neither
of which are actually tags.
- Introducing a new rpmTagVal typedef. It's just an alias for the
"lowlevel" rpm_tag_t type but visually more in line with the other
rpmTagFoo bits - to be used with the "higher level" tags whereas
rpm_tag_t is the "physical" type. Not that it makes any difference...
Spec files have a lot of metadata about a project. However one of the
most key components is the upstream version control system which was
notably lacking.
Resolve this by adding a "VCS" key. There is no specification
for contents of this key, given that the set of version control
systems (and features thereof) are not well-defined. However,
recommendations are:
* git: This URL should be in a form that can be passed to "git clone",
with the additional feature that an optional fragment identifier "#foo"
denotes a branch or tag.
- Two stupid new getters: one for the real tag type, and another
for the return type. rpmTagGetType() returns both requiring bitmasking
all over the place
- Enums are fine for defining the bitfield flags, but the bitfield
itself is not an enumeration. Add a separate typedef on "rpmFlags"
type (presenting a bitfield of flags) for all of these. Compilers
hardly care, but the typedefs give a nice visual clue for
us humans using these flags far away from ho^H^H definitions.
The %sepolicy section is used to describe SELinux policy to be included
in a package. It's syntax is similar to other sections (%files, %pre,
%post, etc.) in that you can provide a string and -n after the
declaration to specify policy should be added to a subpackage.
For example:
%sepolicy
# policy in this section will be added to the main package
%sepolicy foo
# policy in this section will be added to the '<mainpackage>-foo' subpackage
%sepolicy -n bar
# policy in this section will be added to the 'bar' subpackage
The %sepolicy section contains zero or more %semodule directives, with the
following format:
%semodule [OPTIONS] path/to/module.pp
The available options are:
-b, --base
The module is a base module
-n, --name=NAME
The name of the module. If not given, assumes the name is the basename of
the module file with file extensions removed.
-t, --types=TYPES
One or more comma-separated strings specifying which policy types the
module can work with. To explicitly state that a module can work with any
policy type, "default" can be specified as the value. If not specified,
assumes the module can work with any policy type, and assigns the types as
"default".
Below is an example of this new format:
%sepolicy
%semodule -n foo -t mls policy/foo.pp
%semodule -n bar -t strict,targeted,mls -b policy/bar.pp
This also adds new header tags to store the new information:
RPMTAG_POLICYNAMES (string array)
RPMTAG_POLICYTYPES (string array)
RPMTAG_POLICYTYPESINDEXES (uint32 array)
RPMTAG_POLICYFLAGS (uint32 array)
The index of NAMES and FLAGS maps directly to the index of RPMTAG_POLICIES.
However, because a single policy can have multiple types, the mapping for
TYPES is not direct. For this, the index maps to TYPESINDEXES, which
contains the index of the policy that the type maps to. This is similar to
how DIRINDEXES is used to map DIRNAMES and BASENAMES. As an example, the
previous %sepolicy section would have the following header tags:
RPMTAG_POLICIES:
0: <foo.pp data, base64 encoded>
1: <bar.pp data, base64 encoded>
RPMTAG_POLICYNAMES:
0: foo
1: bar
RPMTAG_POLICYFLAGS:
0: 0
1: 1 # assumes flag 1 == BASE
RPMTAG_POILCYTYPES: RPMTAG_POLICYTYPESINDEXES:
0: mls 0: 0
1: strict 1: 1
2: targeted 2: 1
3: mls 3: 1
- Permits basic file verification with just a headerGet(), with some
caveats: there's no way to control which attributes get verified,
and there's no filtering of mtime differences of shared files. Those
aside, rpm -q --qf "[%{filestates:vflags} %{filenames}\n] <args>" now
performs the same as "rpm -V --nodeps --noscripts <args>"
- This hidden gem used "system hdlist", ie "/usr/share/comps/%{_arch}/hdlist
as the source for queries. Such "system hdlist" hasn't existed anywhere
since RHL 9/FC 1 times...
- Add per-scriptlet type flag tags to control special behavior.
- Add rpmlib dependency on scriptlet expansion - if a package relies
on scriptlet expansion it cannot be correctly installed with
a version of rpm that doesn't support it.
- Expansion is always an opt-in behavior, enabled with -q and/or -e argument
in spec. We can't just blindly expand even macros as there's no telling
%{} constructs might mean in whatever language is used for the script.
- Queryformat expansion requires great care with strange and ugly escapes
when writing scriptlets, but OTOH it permits access arbitrary header
data at runtime, which has previously been completely impossible.
- The handling of these expansions needs unifying for all scriptlet types,
the trigger scriptlet handling is uuugly. Macro expansion could be
transparently done from rpmScriptRun(), but because of their similar
syntax, macro expansion needs to happen before query format expansion,
and we dont have the header available in rpmScriptrun()
- add %verify(nofiledigest) as %verify(nomd5) file attribute alias
- reference digests as digests not checksums
- make old md5 related symbols obsolete and use newer reference
- update man page accordingly
Thierry Vignaud