I'm unconvinced that directories need to be treated differently than files.
There has been
%unpackaged_files_terminate_build
since forever. I still believe that the macros need to be removed
and the behavior needs to be made MANDATORY (if desired).
Alexey Tourbin also implemented some silent fixes to add
subdirs that were not specified, which is why you found it
more convenient to add a new macro for directories rarther
than files.
The core issue in need of resolving is when directories should
(or should not) be added to packaging.
I believe that all directories mentioned on every path (including /)
should be added to every package because that is the logical
end-point if _ANY_ directory is added to packaging. One can
quite easily design a packaging system that _NEVER_ includes any
directory, but rather creates directories as needed when mentioned
in file paths, and manages only files not directories, setting directory
permissions as side effects and lazily removing empty directories.
Meanwhile RPM permits both only files and every subdir component
without a clear consensus on what the Right Thing To Do actually is.
OTOH, I personally think that ignoring any/every file not mentioned
explicitly (or implicitly with glob patterns), with an explicit warning
listing all the unpackaged files, is better behavior. Its certainly useful
to cut-n-paste a bunch of paths into a %files manifest and then
adjust to whatever level of macro madness one wishes, a task
I do all the time when creating packages.
All of the rather pugly macro enablers/disablers was Red Hat
control phreak manglement ordered because a FULLSTOP
build failure is all that most package monkeys understand
about proper packaging.
YMMV and my personal packaging checks are clearly different than yours
if we disagree on mileage.
On Aug 26, 2013, at 3:12 PM, Per Øyvind Karlsen wrote:
2013/8/26 Jeffrey Johnson n3...@me.com
On Aug 26, 2013, at 2:24 PM, Per Øyvind Karlsen wrote:
This patch will strip away the buildroot prefix for duplicate files listed,
providing greater consistency with behaviour otherwise.
While the approach is sensible, the deeper flaw is that duplicate
file checks added by Alexey Tourbin around the time of rpm-5.1.9
release do not scale.
Far deeper changes than cosmetically stripping a builroot path are
needed, likely with Bloom filters attached to all the binary packages
produced in a build, so that
/**
* Return intersection of two Bloom filters.
* @retval aBloom filter
* @param b Bloom filter
* @return 0 on success, -1 if {m,k} disagree or NULL pointers.
*/
int rpmbfIntersect(rpmbf a, const rpmbf b)
/*@modifies a @*/;
can be used to detect duplicate (and similarly shared/conflicting) files.
Build a kernel package (which has many more paths than most packages)
and time the additional checks added by Alexey Tourbin if you wish
to see the scaling problem in the existing implementation.
Or try building tests/millionfile-insanity.spec to measure the cost of
the added checks.
Note that the check sadded by Alexey are useful: my only objection is
that the implementation did not (and does not) scale with lots of files.
I can't remember whether I've even actually run into any problems related to
this myself, but on a related note, the unpackage sub directory check is very
often giving false positives..
I have a patch to add support termination of build on unpackaged sub
directories, but considering that the check isn't reliable, I've left it
disabled by default, but I'll attach the patch none the less.
--
Regards,
Per Øyvind
rpm-5.4.10-unpackaged_subdirs_terminate_build.patch
