ISO educational resources to plan a desktop build
 

TL;DR: How does an end user learn about which mid-level packages to build?

I've built LFS several times, but I've never been happy with the end result. I'm 90% sure my dissatisfaction comes from making uneducated choices when choosing which parts of the BLFS book to build. I know I want primarily an internet box with VLC and a bittorrent client. I also know that to make a successful build, it is good to have the end goal in mind. Know where you want to go, and map out the route in advance.

I am a hobbyist. I am an end user. I am not a programmer nor a professional admin. I understand dependencies, even if I don't always remember to compile them in when the time comes. What I don't understand is how "foo" connects to "bar", or why "foo" is a better tool to use than "bar" for a given situation. A real world example might be Qt vs GTK+, or Python2 vs Python3. As an end user, unless there is a dependency prerequisite, how am I to choose between the different routes of implementing and the "big picture" design decisions. Much of the software and accompanying documentation is aimed at developers. My eyes glaze over, and the brain fog rolls in when reading it. I know I dislike the KDE desktop. I remember liking Gnome 2 several years back, and currently prefer Xfce. There are intricacies in the substructure that determine how well the GUI and various programs perform. I do not know how to educate myself about them. These intermediate level decisions honestly can enhance or wreck the end user experience.

Is there a resource or a method that any of you can recommend for people like me to acquire enough knowledge about the advantages and disadvantages of various packages such that we can make good decisions when designing our B/LFS system? I've made random design decisions on the fly, and I've also chose to "build everything". I've never been happy with the resulting OS. Is this just down to experience, trial, and error? Hopefully I have explained well enough that the reader can understand the question being asked.

Is there a good way that I can educate myself and others in a similar position can educate themselves such that we end up with a system that not only is functional, but that we are proud of when it's all finished?

Thank you in advance.
Joshua

hello huffdad,

same feeling after completing my first build from linuxfromscratch.we do/get nothing from that B/LFS OS.it is just understanding purpose.what are the different packages are required and their functionality and their importance etc.in B/LFS book great explanation is given for each and every line of code form that explanation we can learn how that packages work for our custom Os.and what you say about proud moment that moment comes only when you do our own work rather than just copy/paste things upon terminal.so learn from linuxfromscratch or any other and then try your own then you really get proud of your own work.Thanks.:)

Learning systems like B/LFS, Slackware, CRUX, etc. gives you better insight and understanding of how GNU/Linux systems fit together, how packages interoperate, as well as how to understand patching and packaging techniques.

Mostly, you can incorporate packaging systems and patches to create your own unique system for personal usage, or even republish as a public distribution people can use and contribute to.

Thank you for the input.

Carl_cj, I haven't deviated much from the book in the past, but I intend to next time. I don't plan on changing any source code, but I do plan on incorporating some packages that are not included in the book. In particular, there is a thread here in this forum regarding a custom desktop. As for deviations that I hope to see in the future, I'd love to see the X server go away. Honestly, a lot of things that I don't like are part of X.

ReaperX7, I've never tried CRUX, but I've tried probably 15 or 20 distros over the last 5 years. I keep coming back to Slackware. It's "clean" -- for lack of a better term. I have not yet used package management with my builds for the sake of simplicity, but my opinion on that is changing quickly. It will be especially useful for these times when I don't like a change I've made. I'll be able to uninstall the package. That will allow me to step back just a few paces efficiently, instead of trying to manually remove large chunks or restarting from scratch. I'm really leaning towards a Slackware style of package management, although that particular choice is outside the scope of this discussion. For my purposes, I think the "fakeroot" approach to building packages will be the easiest way for me to change my mind if I don't like something. The primary difference in my case will be instead of learning how to install packages, I need to learn how to create packages. A cursory look suggests that shouldn't be too difficult for a personal build. I don't think I'll invest the time yet to develop multi-platform.

I'll leave this open a bit longer in case anyone else offers advice. Hopefully this thread helps others as well. That is my intention.

In the end, probably yes. At least it has been so in my case.

I think I worked backward from the big stuff that I needed and identified the dependencies required. If something didn't fall in with that, it didn't get installed. I use software aid to resolving the dependencies. Gradually, with each new build, more stuff got added. Eventually, new additions slowed, the system was exactly as I wanted, and I began to script the entire thing. That's where I am now. A new build means just reviewing the books for changes and tweaking the scripts for those and version upgrades. I use none of the Linux distros nowadays.

Actually, for me, those examples are non-choices. I install them all (including both GTK+s) as dependencies of one thing or another.

Seriously? In BLFS? I don't think I ever would or could do that. If that didn't turn out well, then you probably needed to install some stuff not in the BLFS book. I do, and quite a lot of it.

To me, that sounds like something that doesn't exist. This is something I have always thought about Linux in general and distros (including BLFS) in particular. The help is out there alright, but it's sort of scattered and fragmented all over the place. It's never collated and organized the way I would like. I have had to figure out all of this stuff one issue at a time using the help for one issue at a time as I was able to find it. I keep detailed notes on what I learn and it all builds up over time.

stoat, thank you for the reply. I am currently mapping my dependency tree backwards from my end goals. I haven't tried to script any of my builds yet, although I suspect that will come in time. Saying I built everything was an exaggeration. "Build everything" was the mentality I had going into it. That was several years ago, and it felt like a bloated distro that was poorly configured. I've taken a "minimalist while fully functional" mentality since then. I'm just trying to properly prepare this one. I've built & discarded enough times, that I'm disgusted with myself for not investing the proper time in advance. I want to do it "right" for a change. I'll know I've succeeded when I use Slackware as a recovery system, instead of a crutch.

For now, I'll keep trucking along one google search at a time! Thanks again.

This is how I personally approach BLFS.

I keep a text file with a tree of dependencies. Like @stoat, I pick what program I want (for example, openbox), and then work backwards and figure out what other packages I need. Writing it down manually on a paper (or a text file) helps me be organized (or at least the illusion to be organized). This way, I can identify whether a particular dependency from another desired packages were already installed. Also, when I uninstall a program, I can check whether I still need the dependencies by looking up in my text file. In my build script (mostly based on Slackware scripts), I do a one-level dependency check, but it is very rudimentary.

Hopefully I'm missing the point of this thread...

Thanks for the reply, kcirick. I'm still in the process of mapping out my dependency tree. Maybe this is yet another thing that I'm overthinking, and I should just let the dependency tree answer the question for me. I'm just trying to think ahead this time and invest in the preparation and research so that I can avoid some of my previous headaches during the build.