On Jun 16, 2008, at 7:22 AM, Jeff Johnson wrote:
On Jun 16, 2008, at 7:07 AM, Alexey Tourbin wrote:
if (jlp->fl_flags & (RPMFILE_EXCLUDE | RPMFILE_GHOST))
continue;
Think of this example:
%install
mkdir -p %buildroot/foo
head -c 1024 /dev/zero >%buildroot/foo/1
ln %buildroot/foo/1 %buildroot/foo/2
%files
/foo/1
%ghost /foo/2
Yes, will fix.
Hmm, at some point, I start to question whether permitting duplicates
like
/foo/1
/foo/1
in %files, or worrying about %ghost (and %attr and %verify and %
exclude and ...,
there's *at least* one other place that the test for %ghost/%exclude
is needed)
scoping over pathologies as in your example above, is worth the effort.
With %ghost, the issue runs to a fundamental spec file design flaw,
there
is plain and simply no way _BY DEFINITION_ to know the file type
associated
with the path that has a %ghost attribute.
The RPMTAG_FILEMODES associated with %ghost files has ugo rwx, but
not the file type.
Why shouldn't all of the above be treated as syntax errors instead
of quietly assuming that indeed, there is some real world need to
have sloppy goosey-loosey spec file syntax permitting duplicates (and
file marker attribute scoping across hard links, or primitive
filtering directives like %exclude) anyways.
But as always, since there's no grammar for spec files, anything goes.
Even with a grammar, the issues of scoping through implicit hard link
aliasing,
are semantic, not syntactical (but duplicates are syntax).
Guess what happens in your example when the install runs with
--excludepath=/foo/1
What link count should be checked with --verify, particularly if
another package also contains
%ghost /foo/2
and /foo/1 explicitly had --excludepath when installed?
And to return to the original RPMTAG_SIZE issue, what value should
--qf '%{size}
report for a given package with excluded hard linked paths that span
multiple
packages as above?
These problems are nearly insoluble with the given precision
of %files during rpmbuild. Does that matter?
Check-in shortly, easier/better to attempt some fix than to try to
discuss the harder issues.
73 de Jeff
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
