Problem with %attr/%defattr

devzero2000 pinto.elia at gmail.com
Fri Oct 7 13:59:00 UTC 2011


On Fri, Oct 7, 2011 at 2:41 PM, Amol Kulkarni <amolk112k at gmail.com> wrote:

> Dear All,
>
> I had built some RPMs for our product on RHEL4  ( rpm ver= rpm-4.3.3-26 ).
> Now I'm migrating these rpms to RHEL6 ( rpm ver = rpm-4.8.0-16 ).
>
> One of the rpms has files owned by different users.
>
> Eg. In qmail queue, "queue/remote" folder is owned by "qmails" user while
> "queue/todo" folder is owned by "qmailq" user.
>
> The qmail makefile creates the files with appropriate permissions and
> ownerships. There is no code to set the permissions/ownership in spec file.
>
> In RHEL4, rpm was automatically taking the file permissions set on the
> files during the build/compile phase. But in RHEL6, it is changing the
> ownership to root.root.
>
> My files section is :
>
> %files
> /var/qmail/bin
> /var/qmail/boot
> %config(noreplace) /var/qmail/control
> /var/qmail/doc
> /var/qmail/log
> /var/qmail/man
> %config(noreplace) /var/qmail/queue
> /var/qmail/users
> /var/qmail/rc
>
>
> After searching the net, I tried using %defattr(-,-,-,-) macro at global
> level and the %attr(-,-,-) macro per entry in the %files section. But to no
> avail.
>
> Can anybody point me in the right direction ?
>
> Thanks for all the help in advance.
>
In rpm 4.4 (Oct 31 2004) was introduced the "add default
%defattr(-,root,root) for all packages". So the "problem" is not only in
RHEL6 but also RHEL5 for example.

IIUC you're basing your spec on  a behavior later deemed incorrect. My
advice, as already mentioned, is to use multiple %attr or use, if you have
many file, multiple %defattr with the right perms and ownership.


hth

> Amol.
>
> _______________________________________________
> Rpm-list mailing list
> Rpm-list at lists.rpm.org
> http://lists.rpm.org/mailman/listinfo/rpm-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-list/attachments/20111007/09dd63f7/attachment.html>


More information about the Rpm-list mailing list