Registo wrote: > As it is now, we have a 'sh' folder, where there are shell scripts for > working with the program, and the 'src' folder, where all the source > files are. Inside 'src' there is one 'cfg' folder, where each client > will have to make a couple of changes (related with their personal codes > and indexes) before building, which is done by a shell script we made > named build.sh, which basically goes into each folder in the 'src' one > and runs the make command for each. You can arrange your source in any organization that makes sense to you. The rpmbuild step won't care. The %build script you fill in the commands needed to build your project. Traditionally this is 'make' or '%makeinstall' but could conceivably be any non-interactive script. > Now, by biggest questions are: > -Is there a way for the user to input the changes to be made in the > files previous to the rpm package building the source files? One design goal of rpm is that building the rpm be repeatable. Prior to package building it was not uncommon for huge differences to appear between two different software builds. Therefore rpm by design captures as much of the build as possible to make it repeatable. If you are trying to make an rpmbuild interactive that won't work and goes against the design goal. Instead capture whatever configuration that you need and run the build non-interactively. > -If so, if the script aborts due to some error, will the rpm also abort? Yes. RPM runs scripts with 'sh -e' and the script exits on errors. > -If not, is using rpm basically as a tar.gz file (meaning it just > unpacks the source files and the user has to make the cfg changes and > build it) the best option (meaning the simpest/easiest) to have version > control with future patches? That paradigm is frowned upon. See item 11 in this reference. http://fedora.redhat.com/docs/developers-guide/s1-rpm-guidelines.html > -If you make a simple spec file, which basically just unpacks the tar.gz > file and doesn't config or build anything, where does it unpack to? As a consumer of some commercial rpms I really despise vendors that try to do that. I usually end up repackaging the rpm. If you create an rpm that simply transports the files and then your '%post' script moves it around then what good is putting it into an rpm? None whatsoever. Better not to hide what you are doing and instead simply give your users a tar.gz file to unpack instead. > RPMs seem like the best way to keep version control, especially because > it's such a widespread protocol. tar.gz files are even more widespread and popular. :-) Bob _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
