But if you're going to learn a DSL for building debs, why not just learn how to build debs? Your distro already provides the necessary build formula, along with well-integrated startup scripts, etc.
To start out, just build as given:
apt-get build-dep nginx
apt-get source nginx
cd nginx-$VERSION
dpkg-buildpackage
Then to customize, go into the source tree and update whatever you want to update, and rebuild. You'll see there's already a debian/patches directory where you can drop patches to apply automatically.
I tend to just keep the "debian" directory in source control, so I can take a fresh upstream tarball, check out my debian rules into it, and kick off the build.
I've done custom debian packages from scratch and always found it a pain. I've also done customized source builds and still prefer this approach because its simple, slimmer, easily version controlled, and wrapped up in a single command.
But there are many ways to fry an egg. I prefer this way, but overall having a package is a big plus for commonality between systems and convenience vs simply building from source.
If you don't care about uptime just replace the old binary with the new binary and then restart the server.
This is from a book called "Nginx HTTP server":
1. Replace the old Nginx binary (by default, /usr/local/nginx/sbin/nginx) with the new one.
2. Find the pid of the Nginx master process, for example, with ps x | grep nginx | grep master or by looking at the value found in the pid file.
3. Send a USR2 (12) signal to the master process—kill –USR2 , replacing with the pid found in step 2. This will initiate the upgrade by renaming the old .pid file and running the new binary.
4. Send a WINCH (28) signal to the old master process—kill –WINCH , replacing with the pid found in step 2. This will engage a graceful shutdown of the old worker processes.
5. Make sure that all the old worker processes are terminated, and then send a QUIT signal to the old master process—kill –QUIT , replacing with the pid found in step 2.
The makefile in the nginx source shows you how to do a hitless upgrade. This is what I do from the shell after correctly installing, essentially translated from the makefile.
This is poor advice that could be potentially damaging. Instead of manually building and installing from upstream source code you should bump the package version locally to ensure your system isn't littered with orphaned files later on. You'll get the benefit of portage's sandbox and other package management features too. If Gentoo's ebuild had Gentoo-specific patches, you'll get these compiled into the latest version as well. Sometimes these patches are very important.
A better approach to follow is (note this is only a rough guide from memory):
I agree that it's a bad way to install new software but I was merely suggesting a way to upgrade nginx that was installed this way in the first place, I assumed the OP meant that by asking for a "stable way to update nginx installations from source.". The fact that I did it on Gentoo is irrelevant here.
I love portage, I use it whenever I can. In this case, I think I've did it like that because something was messed up with Passenger support in the port. It's the only package installed from source (bypassing portage) on my system and it's not an orphan in a way that /opt was dedicated purely for such scenarions. I can see all such packages by listing /opt assuming I keep the install prefix convention.
In any case, thanks for pointing that this is a wrong way to install packages, someone might benefit from this indeed.
Indeed this is what I was looking for (however I will be updating the software on CentOS) sprinkled with a few snippets of wisdom from the above posters.
Looking for a consensus on the most stable way to update nginx installations from source.
Thanks!