Re: FYI: rpmbuild gets slightly stricter, files listed twice now terminates build

Den 12:04 23. januar 2012 skrev Jeffrey Johnson <[email protected]> følgende:
>
> On Jan 23, 2012, at 4:31 AM, Per Øyvind Karlsen wrote:
>
>> It's not uncommon that people accidentally list files more than once
>> in packages,
>> the most common undesired result of this is that directories gets owned by
>> packages they're not supposed to be owned by..
>>
>
> And who determines what rules apply to directory "ownership"?
"not supposed to" as in "not intended [by maintainer]".
Ie. it's not really related to any rules.
>
> Listing files more than once isn't the critical flaw: not
> listing files that SHOULD be owned, or trying to be overly
> clever with patterns and packaging directives and symlinks
> that end up with bloated and surprising file manifests is
> the problem in need of solving.
>
>> Also by allowing this, files might get packaged with the wrong
>> attributes as well.
>>
>
> Well you've stated the flaw: now what is the best fix, not only
> for directory ownership, but also for attribute assignment?
>
> The "… supposed to be …" is almost entirely a fiction mostly
> enforced by packaging policy tuned to expectations that is
> riddled with inconsistencies and driven by opinions and
> fetishes imho.
>
> The only rule I am aware of wrto directory ownership by
> packages that there is fairly widespread consensus for is
>
>        If a package owns all the files in a directory, then
>        it should own the directory as well.
>
> Go ahead and write down the "… supposed to be …" rules. If
> the rules are explicit, then they can be implemented.
No rule. :)
>
> Any other approach is ad hoc and doomed to fail when
> someone invents another rule to handle an exception.
>
> At which time all packages conformant to the previous implicit
> rule set are deemed "broken".
>
> Explicit rules need to be stated first imho.
>
>> So as this might lead to packaging mistakes and there's no reason why you would
>> want to be able to do this, it'll now terminate builds starting with
>> the next rpm release
>> that I'll release.
>>
>
> Making it harder to package by failing builds increases
> package quality at the expense of manual labor and increased
> frustration.
>
> The better approach is rule based, with attempts to resolve
> inconsistencies according to known rules.
>
>> It's really trivial to fix, so no bitching! :p
>>
>
> Yes.
>
> Not bitching here, just saying …
:p

--
Regards,
Per Øyvind