I've been wanting to get back in to capros/coyotos recently, there are 2 distinct issues: a) the main issue is my lack of ability to host a yum repository for the binaries b) the frequency of fedora release cycles (6 months) multiplied by the number of architectures/OS's means a lot of compiling/maintenance, because everybody has their own uprgrade schedule for which they upgrade their fedora installs even if we managed to limit ourselves to a single OS.
with regard to a) the yum repositories require a specific URL format which they are required to comply makes it difficult to find free hosting, I suppose I could talk to the 'rpmfusion.org' guys, and see if I could host as part of that project. (seems like a weird solution to me). a different mechanism entirely has come to mind which would try and attack these 2 problems directly. it has its own unique set of issues... I wanted to see what your opinion was the alternative mechanism would be to host a virtual machine image which has a linux kernel & all of the dependencies required to build capros on it/cross compilers and what not built in to the virtual machine. this solves a) since it's a single image which can be hosted anywhere like mega.com or even on the sourceforge capros page itself. solves b) since we are no longer dependent on fedora's release cycle. also solves c) the requirement of fedora, now we'd just require a qemu/kvm or 'openstack' or eucalyptus or something (haven't gotten down to the details). theoretically anyone running fedora or ubuntu or whatever should be able to run it. it's probably z) slower (not sure how much) y) requires virtualization instructions for the bootstrapping machine x) requires some synchronization mechanism to get binaries out of it and sources to it, so it'd probably complicate the build process. I personally would probably just ssh into the virtual machine to develop, since I never run anything more than bash and vi anyways. that's probably not feasible if someone wants to run some gui editor, if thats the case this might be more painful than it's worth, since it takes the build system away from a process everyone is familiar with. w) requires the initial investment into building the vm images, essentially we maintain a minimal linux or bsd os which we use to bootstrap capros. We could also use the existing RPM's/rpm building and fedora tools e.g. https://github.com/wgwoods/lorax/blob/master/README.livemedia-creator to create the cross compilers vm image, in that case we're staying pretty much the same, we just never build for more than 1 version of fedora... this is probably the simplest way to go, the image will be somewhat larger than we could pull off with a purpose built vm (do we care?) another benefit of the whole 'vm image' based design comes to mind, my qemu image script generation things currently use 'libguestfs', to work around the requirement for root access/fiddling security permissions for mounting a loopback device, so I can install grub for x86 or uboot for arm, or whatever bootloader really. this sort of thing is quite nice in that it allows the build scripts to spit out images runnable under emulation, or that you can install from dd, without any fiddling of the local machine, or multiple steps. libguestfs essentially wraps up a qemu instance granting the user root permissions to that virtual machine allowing them to mount a loopback device. i've really been hampered by the bug here: https://bugzilla.redhat.com/show_bug.cgi?id=737261 in that i have to fiddle with my RPM database in order to get the grub1 installed and hacking the system provided libguestfs to work again (2 years of that and no fix in sight, as it's a stalemate between maintainers) by running the cross compilers in a VM we can quite easily allow the build to mount loopback devices for the parts of the image building process that want it, bypassing libguestfs and the fedora politics involved. anyhow, let me know your feelings on this subject and whether you think this would make it easier to continue development of capros given the current cross compiler situation. another alternative is the openembedded.org style of mechanism, where everybody builds the cross compilers, this is essentially what we have today I suppose with the exception that they do it all in one pass (I haven't looked at their stuff in a while/since the yocto project merge though, it is in all likelyhood somewhat linux target specific). ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d _______________________________________________ CapROS-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/capros-devel
