BLFS remember me the title of an old movie.. "elevator to hell"!
I'm using a lot of paper and you?

Attached Thumbnails

 

I guess all that is referring to dependency hell. I first did that with a text editor and a vertical list. Then I used a software app named depsort that reads a package dependency database file (which I had to create by hand) and can display the installation order of a package and its dependencies or even all the packages in the database file. But once I had my BLFS system like I wanted it, I could build new ones with updated packages using the the same order (or with minor adjustments). So it can be hell alright, but there are some ways out of there. And once out, you may not have to return to it. IMO.

I just keep a copy of the books handy, and archive a collection of sources and build-scripts ripped from the book and Slackware's SlackBuilds. I also document in my scripts required, recommended, optional, and runtime dependencies per package.

Dependency hell doesn't have to be a hell if you avoid the complexity and don't overthink it. It's only as simple as you make it out to be.

The book and properly maintained build-scripts with documentation inside are all you need. Then just archive the sources after building. Easy and simple and you can always dump old archives and scripts.

I maintain my B/LFS build like a FreeBSD system with my own custom version of build scripts like the ports collection. When the Changelog gets updated, I follow suit. I maintain the core of LFS as it's own entity. Afterwards, I update everything but the glibc kernel headers unless I rebuild the system when glibc gets updated. That's when you should rebuild and only then. Otherwise just ride the Changelog and update as needed.

Yes i'm referring to dependencies!
Is like an hell and ok, probably everyone has their own way to go out. Currently i prefer paper and pen and i was just curious to know your way.