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

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"?

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.

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 …

73 de Jeff