Am 19.02.2016 um 14:15 schrieb Josep Manel Andrés:
You are right, I think I will give it a try. So I guess that I will have to prepare two packages (at least) if I wanna run it on a chroot env. bind and bind-chrootenv packages. And I think I should get the specs files from the 9.9.6P1 available on the SLES12 Repos.
one package should be enough, for your own usage you may decide if you want chroot or not and use named on all machines the same way, since you install that one parallel a bind-libs package of the distribution you can even "rm" some binaries like dig and so on in the buildprocess as well as the docs and readmes
one big benefit of a own RPM - my mariadb SPEC has more rm-lines than anything else :-)
On 19/02/16 12:56, Reindl Harald wrote:Am 19.02.2016 um 12:46 schrieb Josep Manel Andrés:I am not too confident to build RPM packages, that is why I wanted to go for a normal installation from source.well, learn it, it's really not hard to do i learnt it the hard way that "make install" over years leaves more and more mess while a rpm package automatically removes obsolete files and the build process finally makes sure that it aborts if anything in the %files section did not exist after compile or a new file is not listed in %files due a upgrade you will notice that when you did a major upgrade which don't work and have no simple downgrade way _____________________________________ additionally normally on a production server you should not install compilers and devel-packages and on the other hand on the build machine install the service with a test config - so you can make sure it will work on the procution machine or find out what needs to be chnaged *before* your service fails you know if your systemd-unit works as expected before it touchs your server by proper testing and the resulting package pulls all dependencies on the target machine (at least on Fedora they are automatically added) _____________________________________ security: if something goes wrong in the build or with "make install" on the production machine you have no way to roll back, "make install" with rpmbuild runs as tesricted user and can't overwrite any files by accident in short: "make && make install" on production servers is a nogoOn 19/02/16 12:28, Reindl Harald wrote:Am 19.02.2016 um 12:25 schrieb Reindl Harald:Am 19.02.2016 um 12:13 schrieb Josep Manel Andrés:Hi Harald, Thanks, but I suspect those are the files that come with the default system installation, but not usable (without modifications) if I have compiled it from source. Am I right?well, it should not be that hard to adopt them for your needs or even build a proper package containing all that stuff - only over my dead body i would do a "make install" on any machine oustide rpmbuildBTW - why don't you just take the SuSE src.rpm, modify the SPEC file for the location where you want to have your own build installed and fire some sed-commands in the buildprocess to scripts and config files? that way you only need to swap the tarball, change the version number in the SPEC and have proper updates in the future
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
