I’m finally working on setting up my home gateway with a Gentoo-based system, as I wrote about some time ago, since I didn’t find anything that looked even barely like what I wanted, off the shelf.
But since the router is going to be working on CF flash drives, I’m also using some tricks to get it up, and this is binging me to find even more problems within Gentoo, but that’s as usual and to be expected, isn’t it?
The first problem is that I don’t want to have superfluous stuff in the router: Portage (I don’t want to live update it), Perl, Python, autotools, other build-related tools, all that stuff should not be there at all. So the obvious is to buil dup my own profile to reduce the system set. This is actually quite boring and a problem in my opinion. Given the stage3 is system itself, to have autotools in the stages (which we do want) we need to have them in system… but they shouldn’t be.
The second problem is that not having either Portage nor autotools in the final system means that the dependencies over Python and Perl of the rest of the packages need to be perfect: no more and no less. Unfortunately sys-apps/file depends on Python unconditionally and util-linux installs a Perl script without depending on it (or having a perl USE flag). If the runtime dependencies are not properly expressed, my router won’t work as intended and that’s going t make me sad, depressed, and probably very angry with those who don’t express dependencies fully. And C++ dependencies will also be a problem.
I’ll be posting some tips and tricks soonish, for now I’m still working on defining what should I add to my router, and how. In particular I’ve been able to do stuff like enabling graphite n the GCC used for building, but not enabling it on the gcc needed on the system, so that it won’t bring in ppl and cloog-ppl, in a quite decent fashion.
Again, being able to prepare this kind of systems programmatically needs more work than just a few tricks and a lot of fighting so you probably will read more about this, and find more bugs about this in the future.
And as a bottom-line: since this is working mostly on stable tree, I also noticed that a few packages that should have been stable already weren’t… so I started opening a few stable requests for my packages; I really need to find a way to make sure they don’t excessively slack off…
I did give up long ago with that, when a stripped down system is needed (fex for virtual servers) I do prepare a list of packages, and use some function to copy the needed stuff from a seed virtual server.
Very funny to see that file issue come up. I filed the same bug about a year ago (see your bug for the number), and I actually talked about it on IRC with some people.There are some strange dependencies that are in the tree for strange reasons. For instance, some packages depend on a minimum portage version, because portage versions older than that were known to be broken. By adding this dependency a certain upgrade path is forced, where portage is updated before a package it will break on.Of course this is one take at it, however it’s a workaround, not a solution.When I ran into these issues, I decided to have my own overlay with almost identical ebuilds that didn’t have the issue, or didn’t have the support for the functionality I didn’t need myself anyway.I definately hope QA will start seeing these issues and will start killing them, it would be an easy step forward for gentoo.Keep up the posts about the router project, I think this might be interesting for a lot of people.
I had similar requirements for an embedded Gentoo based system.At the moment I work with my own striped down profile and doing ROOT binary package installations. This works well so far. Thus I have a very minimalistic system without any build-time dependencies at all.As a last step I would like to run the whole system out of an initramfs without switching the root filesystem to the CF card (and therefore avoid write cycles to the card). In order to support persistent configuration changes, only /etc will be stored directly on the card.
IMO only problem with gentoo is it’s not, and never was, meant to be used like this. I love gentoo and use it whenever possible, but I would never consider device-so-small-it-can’t-handle-portage in “possible” category. You are trespassing on slackware turf here 🙂
radon is right here.. Our default tree is meant to not specify packages in system and you’re long enough with gentoo to know that. Heck we even teach our new people to do it that way for multiple reasons.We want most of our stuff to be straight forward. But when you start paying attention that stuff will also build and run on stripped system, everything becomes a big fat huge mess. No embedded build system out in the wild works on multiple arches and there’s a reason for it. You need quirks wherever you put stuff (even our minor arches proove it) and thus, if there’s a need, fork for a minimal tree but let alone gentoo-x86 on that. Our stuff is complex enough and doesn’t need more complexity just for this…
Do you have ANY proof at all that it’d add complexity to specify dependencies properly?Sorry but that’s bullshit: Portage works fine, and most of the ebuilds also work fine. And surely QA does not teach to *omit* dependencies.
Actually, the dev manual suggests not specifying dependencies on anything in system, unless you need a specific version:http://devmanual.gentoo.org…It doesn’t give a reason for doing it this way, though. I’m kind of curious about the logic behind it.
What kind of hardware are you using to build this router ?Please, keep us giving information about your project! It sounds interesting. 😉