How-To: Git-based package auto-notify.

[DebianJoe]

There are a few tricks that I've picked up since adopting the practice of bleeding-edge system building. I thought I'd share some of the "stay updated" tricks that I use for anyone who might be interested in using this method.

I've said before that over 25% of my user-space is built from source. I tend to pull these directly off of github or sourceforge and build them. This is not a bad way to do things, because it gives you what is essentially the most up-to-date programs available. You're getting them directly from the authors, and if you have issues...you can either fix it yourself and help the author out by putting in a pull-request with your corrections, or you can let the author know what went wrong directly. There is NO middle-man to go through. Now, I've had a guy I work with who I'll call "Mr. openSUSE" who asked me, "So....Debian Unstable is TOO stable and outdated for you?" Well, YES! I run many packages that haven't hit the repos yet, or just were never adopted, and they're some of the very best in my opinion.

The difficult part is keeping everything updated, because you don't have a package manager that will do all of this work for you. The method that I use to stay regularly updated on packages that I use is newsbeuter. Github offers an .atom feed for each author and their commits. So, if you append 'https://github.com/{authors name}.atom' into your 'urls' file in newsbeuter, you'll recieve updates about any changes made to packages that you are using from that author. Now, it will include ALL of their commits, so just worry about the ones that apply to the software that you're using.



If you've kept the original source directory (which I do, because I've got HDD space to spare and am lazy) I can simply navigate to the directory after an update shows up and use:

Code: Select all

git pull

to update my current directory to whatever they're using. I'll rebuild whatever package I'm using from them and that brings me totally up-to-date.

So, what about if something breaks? Luckily, most version control pages allow you to pull a .diff file which is the difference in code from one update to the next. There's also the possibility to use your web-browser of choice to navigate to the author's webpage and read through the commits, checking diffs from one push to the next. This is really only useful if something broke, though. If it works, I tend to just roll on...and at the rate that some devs pump out updates, it's not sensible to have to open a browser and find their website every day. I have found that using the atom feed is MUCH faster.

[DebianJoe]

as an appended item...back up essentials and .dotfiles on external/net storage if you plan to go this route.

The theory is simple. Let's assume that "Carl the Dev" pushed a commit last night after being out drinking and doing cocaine with a few hookers. He may have made a minor change and replaced some of the "make clean" code in the makefile. He meant to use "rf -fr ~/.foobar.d" but passed out and didn't double-check it before pushing the commit after waking up and wondering "where am I?" Now, the "make clean" code just reads "rm -rf ~/" which does what you want it to, plus some.

Don't let Carl's simple mistake totally destroy your life by having you rewrite 9000 lines of lisp in you .emacs file. Make backups of things.

Since you're already using git, that's a really easy way to migrate your files back into any system.

[dkeg]

git is extremely powerful with so many possibilities. I would use often for web dev stuff. Once I got a good thing going, would branch off once and use as a stage for the final stop before merging back to master. then would create a second branch for all work and commits, etc. Once I felt good would merge back to my stage and test. That way kept my master pure.

Using for configs has been beneficial and fun. Nice to set up a new spin and clone over stuff. Also just try to keep my head going and keep some skills.