Re Option B: My understanding is that bootstrapping has mostly been solved by doniphon, but I may have misunderstood.
I believe option A may be the best future for the project. This can be burdensome depending on the packages maintained, but I would argue that we should separate the Desktop and approach it at a later date if there is enough interest (and manpower). It is compelling to me to build a multi-arch core to target popular platforms including systems such as the baglebone and raspberry pi just as much as x86_64. With all the distros out there and mac/OS X swallowing a large portion of people who otherwise might care, a different distro is a hard sale. It is even more challenging to get contributions when we depend on unfamiliar tools (Conary/rMake/etc.) FL2 proved a distro could be made and maintained with great stability and amazingly small amount of manpower. It may be better to push the tooling to other distros, rather than wrapping them. Unfortunately, I discovered with my love affair with Conary, that "good enough" and mind share are very difficult to overcome. Adam On Wed, Nov 20, 2013 at 4:15 PM, Rune Morling <[email protected]> wrote: > On 20-11-2013 11:03, Mark Trompell wrote: >> >> So from what I get from the talks on irc, we're not yet ready to let >> foresight die (which is good I think), >> that leaves us with ~ 3 options. Lets sum them up: >> a) We build our own from scratch base system and maintain it ourselves. >> This will need a lot of manpower and disciplin to keep it running, >> uptodate and maintained for every single package in there. >> b) We define what our base is and just wrap them (no rebuild just >> repack the rpms) >> This will give us a well maintained system (e.g. fedora) that we can >> build anything else on. >> We won't need a bootstrap for this. >> As far as I understood, mirrorball can help us there. This is pretty >> much the boot approach we know from some time ago. >> c) is some sort of hybrid, we don't just fetch and repack the rpms but >> fetch the srpms and rebuild them. >> Mirrorball has its part here too. Not sure of the details yet. Is it >> possible to just use rpm build tools to build from specfile and use >> the result? >> But I want to get the discussion to be on the mailinglist, so that it >> is persistant. >> >> Any thoughts and Details welcome, >> >> Mark >> > > Just a quick note that I have captured the IRC logs in full and have edited > them for continuity. However, Mark's summary above captures almost > everything said, so I see little reason to post them here. > > The only thing that I can see is missing is that António emphasized that > mkj's thoughts would be very valuable, as he is the de facto 'keeper of the > hennery' (i.e. the infra) as António put it. > > With respect to option c), I haven't seen meeuw around for a while, but > maybe it would make sense to try to get in touch with him and hear how his > condora project turned out? As I understand it, mkj's original 'boots' > proposal does indeed map onto option b) and meeuw's condora approach maps > onto option c). > > It is worth mentioning that mkj pointed out that there was a lot of busywork > involved in wrapping binary packages in conary, so I'm not sure what the > value proposition is in option b) if option c) requires the same amount of > manual work yet gives us slightly more control. > > FWIW, I think option c) is what we should go for if at all feasible. Then we > could keep working on option a) as a pet project which, while insanely cool > in and of itself, may or may not turn out to be useful in a production > context. > > > /Rune > > > > _______________________________________________ > Foresight-devel mailing list > [email protected] > https://lists.foresightlinux.org/mailman/listinfo/foresight-devel _______________________________________________ Foresight-devel mailing list [email protected] https://lists.foresightlinux.org/mailman/listinfo/foresight-devel
