On Mar 9, 2011, at 11:53 AM, Per Øyvind Karlsen wrote:
> 2011/3/9 Jeff Johnson <n3...@mac.com>:
>> Nice! And timely!
> But this behaviour is wrong!
>
From an implementation POV, I agree: wrong.
But there are several other issues with %exclude
that are likely b0rken (have been hysterically, I've forgot,
it has been like 5 years ...) including:
1) RPMTAG_ARCHIVESIZE value is incorrect.
The summation of stat(2) st_size ended up double counting
paths mentioned in %exclude
2) symlinks might not be correct.
There's something about symlinks (and follow/nofollow) behavior
that's goofy with %exclude and RPMTAG_ARCHIVESIZE summation.
Meanwhile all that was checked in was a toy reproducer for an issue,
not anything else.
> Why would one add additional functionality to a long existence
> %exclude attribute
> to do the same as what already can be done by using 'rm -rf'?
>
Not suggesting that. But the path of least resistance _MIGHT_ be
to retrofit rpm-4.6.1 behavior (as being de facto what is expected)
in order to get a scheduled/planned transition to "correct" whatever
that might mean.
> And what if one intended to only exclude the file from being archived
> with that specific package, but not from every one (ie. still desired to
> do unpackaged file check on it)
>
> And what's the sanity behind using %exclude skip file from unpackaged
> files check
> for specific packages?
> "Yes, for the packages 'foo' and 'bar', 'foo' is the package that wants to
> skip
> the unpackaged file check the most!"
>
> It makes no sense, if %exclude were actually intended for that
> purpose, it would've
> made a *lot* more sense to not require for it to be used on per-package basis!
>
>
> %exclude only gets included in the list of packaged files because it's being
> passed as a file with a special attribute to *not* archive in that specific
> package. The unpackaged files check didn't know anything about these
> attributes
> and treats files as files..
>
> Here's one previous reference to the topic being discussed earlier as well:
> http://lists.pld-linux.org/mailman/pipermail/pld-devel-en/2007-July/019221.html
>
> Pleeeaaseee don't make me having to try explain the logics and cause of the
> specific bug that's not really in our rpm version even to begin with. gaaah!
>
I agree with most of what you said.
(aside)
Hysterically, I got yelled at in 1998 because RPM did not have
an "everything but ..." functionality (aka %exclude).
Because of who yelled, I slipped %exclude into RPM as soon as it appeared in
PLD.
This was rather late in some RHL release cycle of yore, so there was no time
to fix what was wrong then, or until much later like rpm-4.4.2 because of
other higher priority work like multilib and SElinux and --rollback.
So the hysterical facts are that %exclude has never really been "correct",
and the mixture of behaviors has likely poisoned the usage well (That also
happened with RPMTAG_VERIFYSCRIPT in rpm2.x, where a typo caused the
tag to not work correctly and noone noticed for 1-2 years. YOu can
still see the effects of the brain fart today, where almost no *.spec
files and *.rpm actually have %verify scripts.)
Make sense? I do agree that the behavior in 4.6.1 is less "correct",
but that's never stopped the RFE's for "compatibility" from happening.
And sadly, "compatibility" will never ever be achievable.
73 de Jeff
> --
> Regards,
> Per Øyvind
> ______________________________________________________________________
> RPM Package Manager http://rpm5.org
> Developer Communication List rpm-devel@rpm5.org
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
