- When an existing config file content changes between package versions
but the file has already been changed to match the content of the
new version, we still create a backup file that's identical
to the one that ends up being installed. This is a bug of sorts,
but documenting the existing behavior before changing it.
- Prior to commit f7f5f88f9f, this
would've failed: removing the last package to be installed would
cause timestamp failure on all others. The order is arbitrary in
this testcase but it matters in real-world situations such as
secondary arch packages.
- When packages share an identical file, we only need to create the
first one we encounter and skip it for the rest (reverse already
happens, and must happen, on erase). This has the benefit of
getting the timestamp to match the first file, which often is
also the last one to get removed. Also when lots of shared files
are involved (such as in multilib installations), this can give
several percents worth of speed gain as we dont unnecessarily rewrite
the same contents over and over.
- Commit 429b933b42 fixes the fd-leak
regression in rpm 4.10, but we already have code which relies
on the new behavior and segfaults with the former one. Adjust
rpmcpioClose() to the old behavior to get master tree back to
working shape. TODO: fix this properly some rainy day (oh and see
http://geekandpoke.typepad.com/geekandpoke/2012/08/likelihood.html)
- This reverts commit 4c1f7e335de1724661ce63c53186d161ab71a63f:
various things inside and outside of rpm actually do still depend
on the old behavior, and leak file descriptors otherwise.
As an easy backportable band-aid, revert back to the previous
behavior, to which various callers are tuned to fix the regression
introduced in rpm 4.10.0. The real fix would be something more like
"eliminate fdFree() and make Fclose() honor refcounts".
- Fixes fallout from commit f9c69f803f74bd458269c7a06def494ea63387e6:
running these tests with -Wstrict-prototypes causes all these tests
to fail as AC_LANG_PROGRAM() uses an incomplete prototype for
main() :(
- All rpm versions log a bogus "unclosed %if" error when %include
is used inside %if-%endif (and rpm >= 4.10 actually aborts the
parse): the check for unclosed if occurs before checking whether
there's more to come.
- Move the error check into readLine() EOF path along with the other
similar check to fix, and to consolidate the error handling to
a single spot.
- Verifying files against the originating, non-installed package can
be useful sometimes, eg if rpmdb is broken or cannot be trusted.
Of course such verification will give false positives on files that
were intentionally skipped during installation (nodocs, wrong color,
netshared...), that can't be helped.
- This restores the former behavior that was erroneously changed
in commit adbd484372 while "fixing"
an unhandled enumeration in the switch. Doh.
- Some vendors insist on calling their x86_64 packages "em64t" instead
of the more standard x86_64. Minimally support this naming convention
as those packages aren't going away anytime soon - be liberal in
what you accept and all, sigh.
- As noted (but since then blissfully forgotten) in the commit message,
commit e696b409fe broke --badreloc
so its been broken since rpm >= 4.9.x :-/
- Transaction problem filter is only available during rpmtsRun() so
we have no clue whether bad relocations should be filtered or not
during rpmte creation. Instead of creating the problems at rpmteNew()
time, remember any bad relocations that were found and check +
create the actual problems (unless filtered) along with other
problems during rpmtsRun().
- Passing an "allow bad relocations" flag to rpmtsAddInstallElement()
would be a saner option but this is a back-portable way of handling it.
- For now there's no way to set this flag from packages so it doesn't
actually do anything, but it doesn't hurt anything either, allows
Suse & friends to drop one patch (greetings Michael :) and there
are might be some things we could use this for internally.
- Unfortunately patch'es idea of "interesting" output is not ideal for
our purposes: "patching foo.c" is of little value, but hunks with
offsets and fuzz can be important and there's no switch to patch
to get exactly what we want. So let it be chatty... build logs are,
anyway.
- Ability to skip %clean build stage was requested as RhBug:756531,
--nocheck seems otherwise useful to have as %check can take a lot of
time, time you might not want to spend for a trivial spec change or such.
- The strict date validation introduced in commit
a29e5f9894 is too much of a PITA
for such a petty cause, mismatching weekday names as very very
common in specs. Maybe we can change it to a hard error in a couple
of years from now once folks have had time to get rid of the
warnings first.
- Shouldn't change actual functionality, just makes the code easier
to read and fit on screen by reducing indentation level.
- Add further commentary about what it does and why.
- Directories can be explicitly specified via either %dir or trailing
slash in the %files manifest, take this into account for %ghosts that
dont exist in the buildroot. Otherwise we still assume regular file.
- Dont require explicit %attr() for missing %ghosts, let them fall
back to %defattr() instead. If %defattr() doesn't specify a mode
the file will be seen without any permissions at all, but that's
not strictly an error (and same can happen with %dev() already)
- There's no (relevant) additional information to be gained from passing
directories to libmagic and we already have this info available in the
file mode. This permits nice and easy handling of %ghost directories
(related to RhBug:839656)
- Allows arbitrary length line continuation constructs in specs, but
probably the more useful side-effect is cleanly handling unterminated
macros and the like (instead of segfaulting) on large spec files,
there was a bug on this somewhere but cant find it atm.
- This also has a wee bit silly effect on the maximum macro expansion size:
after very long constructs the max expansion gets is bigger than
at the beginning of spec parse, but properly fixing the resizing wrt
macros is a different issue.
- Watch out for possible fallout from spec->line etc tracking, they
*seem* to be ok even with the potentially moving buffer location but...
- The previous rules far too specific to glibc + gcc with certain
optimization levels, eg relying on parse_auxv() getting inlined
and when it does not, the suppression rules would no longer match.
- Compare the date parsed from changelog to date normalized by mktime()
and complain if they differ. This catches cases like wrong weekday
specified for an otherwise valid date, and a leap day on a non-leap
year etc.
- Previously packages which had no files or for which automatic
dependency generation was partially or fully disabled didn't get
any of their dependencies printed out at build-time. This doesn't
affect the actual recorded dependencies, only the "debugging"
output during package builds.
- On gcc versions supporting -fstack-protector, not all platforms
support this feature, causing gcc to emit only a warning instead
of an error. Which then causes warning-spew on every compiled file.
Run all the supported flag tests with -Werror to turn the warnings
into errors, there could be other similar cases besides stack protector.
- Patch originally from Arnaud Patard according to this Mandriva commit:
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages?view=revision&revision=448632
- Defaults should be for the common case with disablers for those who want
to do something special, and typically if you have patches you also
want to apply them. Change it while we still can: eliminate -A option to
%autosetup and apply all patches unless -N option is used.
- Both Maximum RPM and the newer RPM Guide incorrectly list "owner"
as a valid %verify() attribute, whereas rpm has used "user"
for as long as the code has been present (since 1996). Since
adding the alias is so trivial, and certainly easier than changing
published books... meh.
- At the time when the file list is being processed, we dont yet
have the slightest clue what kind of payload will be used for
for the archive or what limits it might have. Let the cpio code
handle its own limits checking, the build-side only needs to
worry about whether 32bit uints are sufficient for storing the
sizes in headers.
- Commit 4cb02aa928 asked to see
what breaks when mmap() is used, now we know: large package support
broke when enabling it. Could be fixed of course by eg adding
a size cap to the fsm part as well, but just doesn't seem worth it:
I fail to measure any meaningful performance improvement from mmap
usage in either case, and added complexity for what is close to
zero benefit just doesn't make sense... and various sources in fact
note the rpm usage (read through the entire file sequentially) as one
of the cases where mmap() is NOT beneficial due to mmap() high
setup + teardown cost + page fault speed (or lack of thereof).
- Refer to RPMTAG_* for rpmds tags, not RPMDBI_*. The values for these
are the same, only the "intended use" differs (RPMDBI refers to
rpmdb indexes) so this doesn't change anything in practise.
- dbtag cannot possibly be on obsoletes here, we need to look at deptag
instead. This thinko in commit 5f1ec21518
renders that whole commit useless. Doh.
Panu Matilainen