On Mon, 2013-09-09 at 17:23 +0530, Shridhar Daithankar wrote: > On Monday, September 09, 2013 07:28:43 AM Michael H. Warfield wrote: > > In the git-stage current Fedora template, the entire problem is embodied > > in the "download_fedora" function starting around line 201... The > > gotcha's are three commands around line 272 after we've identified and > > downloaded the initial release rpm. We have this: > > > > mkdir -p $INSTALL_ROOT/var/lib/rpm > > rpm --root $INSTALL_ROOT --initdb > > rpm --root $INSTALL_ROOT -ivh ${INSTALL_ROOT}/${RELEASE_RPM} > > $YUM install $PKG_LIST > > > > Ok... Those are running in the host local run time environment. > > Obviously, if the host does not have a (compatible) version of rpm > > and/or yum in the host local environment, you're screwed. That's the > > catch-22 situation and it's the same situation with zypper in the > > OpenSuse template. That short space of code has to be recreated in a > > totally distro-agnostic manner so it runs on any distro to create our > > initial rootfs. After that, we can do what ever distro (Fedora) > > specific commands we want by chrooting into the target container first > > (including rebuilding the rpm database to the target version). That's > > only even needed if you don't already have a cached rootfs for that > > distro and version.
> Another approach could be to popularize the container downloads by the > distro. > If each distro. could add a .tar.gz for a working container of a given > release, one could just download and configure them, no? > then the lxc project upstream, could just list those links or include them in > the a separate tool, that just downloads and untars the same? > That would completely sidestep the bootstrapping one-distro.-on-another > problem. True, and that's been mentioned before in several different contexts. The problem is that we have to get the cooperation of ALL the distros we wish to support, which seems to be a bit of an intractable problem. In Fedora, it would require someone to take that on as a project and be the maintainer. It would also have to be architected into the build system so it would be automatically build when a release it cut. Since they already have the squashfs LiveOS system (which is 95% of what we need), I don't think it would be a major leap for them to add a parallel build to build an LXC LiveOS to live, say, in the same download directory. In fact, if they fixed some of the deficiencies in the LiveOS image, we could work directly from the squashfs image that's already there. The problem is in getting someone interested (I'm not a Fedora maintainer) and getting them to do it. It would probably have to be filled as an enhancement request and go through the months long vetting process at best. We might have a better shot (in this case) of filing a bug report in bugzilla for the busted components of the LiveOS image and getting them to fix it. Even there, though, it's likely impossible to get them to retroactively fix any of the previous images. I agree it would work, I just don't think we can depend on getting everyone else to agree to it and implement it in their distros. Considering the direction Fedora has been taking in recent decisions (removing sendmail / any MTA as well as the syslog server from the base install) makes me seriously question if they would even care. > -- > Regards > Shridhar Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
_______________________________________________ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users