Note what it says in the README that was left behind in the dcload directory (and similarly what's in the lone file in the kos directory in the SVN). Nothing's been removed, its just been moved away from SVN to Git.
I don't recommend that anyone "pre-package" KOS itself until there is a formal release again. Its kinda silly, considering you'd be pre-packaging a work-in-progress version that may be between two very large changesets. I won't stop you from doing it (there's really no way for me to do so, even if I wanted to), but I recommend highly against it.
That said, there are no "dependencies" for KOS itself other than a working compiler toolchain (which implies some host tools like make and such). GCC itself has a few dependencies (GMP, MPFR, and MPC), all of which are noted quite plainly on the GCC website (and of course, having a host version of GCC is required to compile GCC). Once you have those dependencies, dc-chain (which is included with KOS) takes care of the rest of the work.
I've never been a fan of pre-built toolchains, as I find they generally take up way too much bandwidth to host and will break unless everyone has the same exact setup as you do (which they likely won't have on Linux or BSD or whatnot). As stated before, I won't stop you from doing such a thing if you really want to, but I would generally find it a bit of a pain myself. Plus, if you're going to do such a thing, are you willing to maintain it afterwards when things change? People tend to get frustrated when they start with a pre-built toolchain and want to update it, but have no idea how without someone giving them a new pre-built toolchain. This is the exact complaint about things like the Dreamcast Dev ISO that tends to frustrate new Dreamcast people so much that they give up when nobody knows how to help them with their issues with it.
I don't want to necessarily talk you out of making such a thing, I just wanted to bring forth some issues you'd face along the way, and point out why I'd probably never make such a thing myself.