- Legacy generators dont create a dependency dictionary, in which
case there's no point adding per-file depends dictionary indexes
(all zeros) either. Should've probably been in
commit 05636a7db2 already.
- There's no good reason for having a "current index" within fc,
and the code is easier to read when its clear its just an index
of a silly for-loop and not something fancier.
- File coloring affects ability to install packages on multilib
systems when relying on color conflict resolution (eg Fedora, RHEL),
and that has zero to do with whether package dependencies are being
automatically generated or not. Always generate file classification
and the coloring based on that.
- Besides fixing coloring where AutoReqProv: 0 is used (ie RhBug:1150209),
this also fixes two issues when the legacy external dependency generator
is used: file coloring (RhBug:lotsa) and config() dependency generation.
So in default configuration, internal vs external depgen now only
affects whether dependencies are recorded on file or package level,
otherwise the produced packages should be fully equivalent now.
- Tar defaulting to preserving owner etc makes sense for its normal
uses, but for rpmbuild its not a good idea, ownership needs to be
set in spec for consistency and sanity.
- Fixes regression from commit 7f84a126ab
which causes archive size to be determined before closing the archive
when closing actually writes the cpio trailer into the archive. Thus
RPMTAG_ARCHIVESIZE (and RPMTAG_LONGARCHIVESIZE) are off by the
cpio trailer size in all packages built with rpm 4.12.0 and
pre-releases :(
- Move rpmcpioFree() to rpmfiFree() to allow Tell() on the archive
after closing it, swap to original order of things on build-side.
- As hysterical as it seems, people keep banging their heads into this:
older distros have these invalid dependencies deployed etc and people
do expect to create srpms and do test-builds on newer distros they're
running themselves. Which, put that way, seems rather reasonable...
- For history reference, the sanity check was originally introduced in
commit b2cf1471bb and
67ccf8d996,
- Commit 0bda2faa4d fixed manual
dependencies in rpmspec queryies, but missed automatic self-provides.
Add the self-provides before the first round of header dependency
population to fix. SIGH.
- Another sorta related side-effect is that the exact order of rpmspec
output changes as things are now properly sorted, previously it
was a mixed bag.
Rich dependencies will be stored as a string with no EVR and the
RICH flag set. This unfortunately means that we have to parse
them again when checking dependencies.
Also add a rpmlib() marker when a rich dependency is used as
conflicts or requires dependency.
- Yet another regression from the recent dependency refactoring and
ensuing patches-on-patches-on-patches work: some rpmlib() dependencies
(payload, tilde) are added as late as writeRPM(), those have been going
to /dev/null recently.
- The fix actually removing code is probably a good sign...
- 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?
- Another regression from the recent rpmfc work, in rpmdeps context
there's no spec or packages from it. Allocate a dummy package so
we have some place to store the dependencies. And yes its ugly.
- Commit 0bda2faa4d caused a regression
where rpmlib() dependencies are no longer added to src.rpm packages
as the header is populated early, whereas rpmlib() dependencies
get added late in the game. So nothing was pushing the rpmlib
stuff to header. Sigh.
- Since commit a357c99c58 the dependencies
are no longer in the header so there's little to print from there.
As it happens things are much saner this way, we no longer need
to create rpmds'es just to print stuff.
- Didn't realize there's rpmdsTagTi() now, which is fit for this
purpose and doesn't look as much out of line with the others.
No functional changes here though.
- Fixes regression introduced in the regression-fix
commit 0bda2faa4d, *facepalm*
- Unlike other dependency types, trigger dependencies involve a fourth
tag which we forgot to delete before adding again, causing duplicate
trigger indexes
- Similar to commit 1b41c91431, rpmspec
and other tools expect to find manually specified dependencies
from the headers of a freshly parsed spec. This means we need to
add this cruft two times: once for the manual dependencies and then
scratch all that and redo from start after automatic dependencies
have been discovered at the end of package build.
- Fixes another regression (rpmspec dependency queries went dead)
introduced in commit a357c99c58
- BuildRequire checking requires a header populated with dependencies,
commit a357c99c58 changed this to
occur too late for this purpose. Move to initSourceHeader() seems
to fix, also goes to show we dont have a test-case for buildrequires...
- Its never been used beyond assignment to the internal state struct,
so in reality this is entirely free of any rpmbuild-specifics.
Meaning we could trivially lift it to librpmio for macros...
- No functional changes here
- Our libraries are in reality so interdependent that its not even
possible to use them independently of others, so having them
all follow sort of independent versioning information just doesn't
make any sense and is a PITA everytime I need to touch the data.
- This causes librpmsign soname bump with no good reason so its
probably "evil" and all ... so sue me, its not as if anybody
is actually using this library outside rpm itself.
- 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>
Panu Matilainen