Is there another reason besides rpm automagic stripping (+ laziness or something like that in not resetting to 644 in the specfile later) for all *.ko to be executable by root (mode 744) in the kernel package?
On Sat, 2004-09-11 at 19:09, Ville Skyttä wrote:
Is there another reason besides rpm automagic stripping (+ laziness or something like that in not resetting to 644 in the specfile later) for all *.ko to be executable by root (mode 744) in the kernel package?
well..... the stripping happens during the final rpmbuild stage; I don't have scripts running after that, it's pure RPM itself from that point on
but other than the strip-to-file there is no reason indeed
On Sat, 2004-09-11 at 20:39, Arjan van de Ven wrote:
On Sat, 2004-09-11 at 19:09, Ville Skyttä wrote:
Is there another reason besides rpm automagic stripping (+ laziness or something like that in not resetting to 644 in the specfile later) for all *.ko to be executable by root (mode 744) in the kernel package?
[Apologies, this sounded more foul than it was supposed to...]
well..... the stripping happens during the final rpmbuild stage; I don't have scripts running after that, it's pure RPM itself from that point on
You can always "reset" the attributes using %attr in %files. One solution would be to create a file list during the "find" in BuildKernel(), and use that later on, something like this (definitely incomplete and buggy, but just to throw in the idea):
rm %{name}-%{version}-%{release}.files for file in find $RPM_BUILD_ROOT/lib/modules/$KernelVer -name "*.ko" -type f ; do chmod u+x $file echo $file | sed "s|^$RPM_BUILD_ROOT|%attr(644,root,root) |" \ >> %{name}-%{version}-%{release}.files done # Add similar stuff to handle dirs and files other than "*.ko" in # $RPM_BUILD_ROOT/lib/modules/$KernelVer here
[...]
%files -f %{name}-%{version}.files
but other than the strip-to-file there is no reason indeed
Ok, thanks for the confirmation.
On Sat, 2004-09-11 at 20:23, Ville Skyttä wrote:
On Sat, 2004-09-11 at 20:39, Arjan van de Ven wrote:
On Sat, 2004-09-11 at 19:09, Ville Skyttä wrote:
Is there another reason besides rpm automagic stripping (+ laziness or something like that in not resetting to 644 in the specfile later) for all *.ko to be executable by root (mode 744) in the kernel package?
[Apologies, this sounded more foul than it was supposed to...]
well..... the stripping happens during the final rpmbuild stage; I don't have scripts running after that, it's pure RPM itself from that point on
You can always "reset" the attributes using %attr in %files. One solution would be to create a file list during the "find" in BuildKernel(), and use that later on, something like this (definitely incomplete and buggy, but just to throw in the idea):
ok now it's my turn .. ;-) is having the modules executable an actual problem? If so in what scenario ? Before going down a semi complex and probably somewhat fragile road I'd like to be sure there's a real problem getting fixed by something like this and not just something cosmetical...
On Sat, 2004-09-11 at 22:03, Arjan van de Ven wrote:
is having the modules executable an actual problem?
AFAICT it's the same problem or non-problem as with any file out there if a file that is not meant to be executable has executable bits set. But I believe it's pretty much cosmetic in this case.
The reason I was asking are separate extra kernel module packages; in those it's usually trivial to tune the permissions to be "correct" and still have rpm auto-strip them. Or at least more trivial than in the actual kernel package as currently implemented.
On Sun, 12 Sep 2004 06:52, Ville Skyttä ville.skytta@iki.fi wrote:
On Sat, 2004-09-11 at 22:03, Arjan van de Ven wrote:
is having the modules executable an actual problem?
AFAICT it's the same problem or non-problem as with any file out there if a file that is not meant to be executable has executable bits set. But I believe it's pretty much cosmetic in this case.
http://www.yak.net/carmen/unix_horror.html
Go to the above URL and search for the submission from mike@sojurn.lns.pa.us .