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

On Mon, Jan 23, 2012 at 4:19 AM, Per Øyvind Karlsen
<[email protected]>wrote:

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


So POK just curious how do I properly do this?

the following in a spec:
%dir %{_datadir}/unity
%{_datadir}/unity/

 gives me this error now:

error: File listed twice: /usr/share/unity

http://kenobi.mandriva.com/queue/failure/cooker/contrib/release/20120124162224.mattydaw.kenobi.4858/log/unity-asset-pool-0.8.22-1/build.0.20120124162346.log