There should be a tool to automate acquiring clients. Tools like debootstrap and pacman can make a client, but they largely depend on a similar client already existing due to dependencies. This tool should be very portable to avoid that limitation. The tentative name for the tool is "brg".
Tentative work on brg is being done here. Note the script itself and support scripts.
My current work is in https://github.com/meinwald/bedrocklinux-userland/tree/brg
So far I have been mostly working on a CentOS support script, but fixed some small issues in brg and the Debian support script.
Current status of the CentOS support script is that it will install CentOS 6 reliably (at least in my own testing) but I'm working on a strategy to install any version of CentOS. There are two main barriers to this:
Current plan to combat this is to use CentOS 6 sqlite regardless of release selected. This does address (1) and (2) but has the disadvantage of requiring that the mirror provided includes CentOS 6.
My goal on this issue is to make all existing support scripts feature complete (support all applicable options in brg) and add a -g option for group/task installs to complement the existing -p for packages. At that point, I'll work with paradigm to determine who will handle future development.
CentOS 6 sqlite requirement just a temporary measure, or planned for the long term? If it is just a work-around for the limitations of CentOS 5's sqlite, with the expectation of using the target release's native sqlite for future releases, that should be fine, I think. However, if the plan is to use it going forward:
I expect those requirements may be a bit naive. I could give up on them later if we can't pull it off, but I'd like to try.
Is the concern that you are using sqlite to resolve dependencies, and thus have a catch-22 about what to use to resolve sqlite's dependencies? If so, I may try to find some alternative solution (likely using the XML document instead of sqlite for dependency information).
If none of these are found to be viable, we can certainly fall back to using CentOS 6's sqlite for as long as it is available. CentOS 6 is not going anywhere anytime soon.
I'll be happy to take future development back from you once you're happy with the part your working on. Didn't mean to imply any pressure by assigning this to you.
Ideally this would just be a workaround for CentOS 5 and older. There are two distinct issues, the first being changing dependencies for sqlite. Due to the infrequent releases of CentOS, I am comfortable, at least for the time being, tracking the dependencies for sqlite and keeping that able to bootstrap on all CentOS 6+, so those should all be able to work natively. I think the vast majority of users will be wanting CentOS 6+ at this point due to the age of CentOS 5, so while I will support CentOS 5 and lower, I think it is reasonable to use a workaround for it.
As far as parsing XML, that would solve the problem, but it is tricky to implement correctly. To comment on your suggestions:
There are potentially a few ways this can end up working without adding in XML parsing, and it will be hard to see which is best until CentOS 7 is released (RHEL7 beta is out but they organize things a bit differently). I still think the workaround for CentOS 5 and lower is the best we can do now, but if there were other uses for parsing XML in core Bedrock or XML code were otherwise brought into core, I would make use of that.
I haven't had as much time as I thought I would this past week, but I should be able to get the CentOS 5 workaround code written in the next week or so. At that point, it may be clearer what is workable.
For now assume no fancy new XML stuff. If the dependency resolution stuff is sufficiently compartmentalized/modular I expect we can always go back and change it. No pressure on the time tables.
Updating the issue with the current line of thinking about this project:
There are three strategies being pursued:
The primary sticking point at the moment is RHEL-based distros (other than Fedora). Information such as dependencies is provided in both XML and sqlite. Parsing either of these with just busybox is undesirable, making strategy (1) undesirable as well. The CentOS installer, and presumably other RHEL-based installers, does not actually come with yum installed in the installer. Thus, we cannot utilize yum from the installer to determine dependencies. Moreover, option (3) does not seem to exist for CentOS.
To resolve this sticking point, we may have to do one of the following: