Rpm setting owner to build user

[Dan Ciarniello]

I am trying to build an RPM for apache. When I install the package, RPM
insists on setting the owner of the files to that of the build user
rather than the user specified in the spec file. I have created a
couple of other RPMs that don't have this problem so I don't understand
why this is happening. Does anyone know why this might be happening?
Here's the spec file that I'm using:

=============================== CUT ============================
%define targetdir apache2
Summary: Apache Web Server
Name: httpd
Version: 2.0.55
Release: 1
License: Apache Software License
Group: System Environment/Daemons
Source0: httpd-2.0.55.tar.gz
Source1: httpd.sh
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root

%description
Apache Web Server

%prep
%setup -q

%build
./configure --enable-ssl=shared --enable-so --with-ldap --enable-ldap
--enable-auth-ldap
make

%install
rm -rf $RPM_BUILD_ROOT
make DESTDIR=$RPM_BUILD_ROOT install

mkdir -p $RPM_BUILD_ROOT/etc/profile.d
install -m644 -p $RPM_SOURCE_DIR/httpd.sh $RPM_BUILD_ROOT/etc/profile.d

%post

%clean
rm -rf $RPM_BUILD_ROOT


%files
/usr/local/%{targetdir}
/etc/profile.d/httpd.sh
%defattr(-,root,root,-)
%doc


%changelog
* Thu Nov 8 2007 <***@saturn.cityxpress.com> - 2.0.55-1
- Initial build.
=============================== CUT ============================

Thanks,
Dan.

[Tim Mooney]

Post by Dan Ciarniello
%files
/usr/local/%{targetdir}
/etc/profile.d/httpd.sh
%defattr(-,root,root,-)
%doc

Does it make a difference if you move the %defattr up so that it's the
first thing after %files?

Tim

[Dan Ciarniello]

Post by Tim Mooney

Post by Dan Ciarniello
%files
/usr/local/%{targetdir}
/etc/profile.d/httpd.sh
%defattr(-,root,root,-)
%doc

Does it make a difference if you move the %defattr up so that it's the
first thing after %files?
Tim

Yes, it does. Thanks, Tim.

One thing that didn't make sense at first was that the problem only
occurred for this rpm and not others; all had the %defattr after the
files. I eventually realized that I was building on two machines - one
Fedora Core 4 and the other RHEL4. The rpmbuild version on FC4 is 4.4.1
while that on RHEL4 is 4.3.3. Apparently, in 4.3.3 the %defattr only
applies to files following the directive while in 4.4.1 it applies to all.

Thanks again,
Dan.

[Jos Vos]

Post by Dan Ciarniello
One thing that didn't make sense at first was that the problem only
occurred for this rpm and not others; all had the %defattr after the
files. I eventually realized that I was building on two machines - one
Fedora Core 4 and the other RHEL4. The rpmbuild version on FC4 is 4.4.1
while that on RHEL4 is 4.3.3. Apparently, in 4.3.3 the %defattr only
applies to files following the directive while in 4.4.1 it applies to all.

No, that's not the reason.

At some point the %defattr(-,root,root,-) became the default, probably
since RPM 4.4. Try to remove it, and you'll probably see that it still
works on your FC4.

But for the reason you now discovered, I don't want to use this feature
in my spec files yet (maybe in 10 years or so... ;-)).

[Jeff Johnson]

Post by Jos Vos

Post by Dan Ciarniello
One thing that didn't make sense at first was that the problem only
occurred for this rpm and not others; all had the %defattr after the
files. I eventually realized that I was building on two machines - one
Fedora Core 4 and the other RHEL4. The rpmbuild version on FC4 is 4.4.1
while that on RHEL4 is 4.3.3. Apparently, in 4.3.3 the %defattr only
applies to files following the directive while in 4.4.1 it applies to

all.
No, that's not the reason.
At some point the %defattr(-,root,root,-) became the default, probably
since RPM 4.4. Try to remove it, and you'll probably see that it still
works on your FC4.

Yes, in order to establish a sane default. When building as non-root,
the original default values for owner/group (the ownership of the files
being packaged) was no longer sensible.

The other problem is that %defattr has never had clear scoping across
a set of files. Consider what happens with file manfiests that are either
appended or prepended to the %files manifest. The scoping has always been
across the remainder of %files, not within scope of the manifest, and so
there were similar "changes in behavior" when automated tools started
to add a %defattr automagically (like 5 years ago?)


But for the reason you now discovered, I don't want to use this feature

Post by Jos Vos
in my spec files yet (maybe in 10 years or so... ;-)).

Its rather easy to implement any desired behavior. Its impossible to please
everyone.


73 de Jeff