John Pye wrote: > I guess I didn't put that very clearly. The issue I'm talking about is > those packages that come with wierd installer scripts that are > interactive or download files along the way, or whatever else. An > example is the following: > http://www.smlnj.org/dist/working/110.59/index.html I *hate* those hacked together rpm packages. I did not look at the one you referenced in detail. But I have run into others similar to your description before. The are usually a PITA and I usually end up needing to repackage them if I use them. (Intel's C/C++ compiler jumps to mind immediately.) > Unfortunately this happens to be a prerequisite for a rather important > piece of software that I've been wanting to build. But without > unleashing this script on my root account, I can't proceed. With > fakeroot, I'm thinking that I could wrap up that whole installer process > and come out with at least a reasonable starting point for an RPM, > without having to totally rewrite the install scripts for that big scary > piece of software. Using fakeroot there seems like a pragmatic approach. You may find that if the scripts try to run ps and then kill and restart services that they are too nasty even for fakeroot to work around. But nothing ventured, nothing gained. > I've come across these types of packages more than once: you can spend a > long time getting a non-standard installer script to the point where it > is 'rpm friendly'. I think that perhaps if fakeroot were integrated in > to RPM in some way, there might be a chance of saving some time in these > situations. It seems that dpkg provides this capability, although I > can't say I understand it in any detail. I don't think it needs to be integrated into rpm. Only broken packages need it and writing into rpm a way to support broken packages would be adding to the breakage. Fortunately it is not needed. Instead simply run rpmbuild under fakeroot. Then everything in the embedded scripts will be all wrapped all at one time. fakeroot rpmbuild -ba foo.spec Let me state this explicitly for the mail archive. A well-behaved rpm package definitely should not need this. But as a workaround for badly written packages it may be useful. Bob _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
