That will be great, i was looking for something like this.<br><br><div class="gmail_quote">On Thu, Nov 25, 2010 at 9:11 AM, Jerry Vonau <span dir="ltr"><<a href="mailto:jvonau@shaw.ca">jvonau@shaw.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">On Wed, 2010-11-24 at 22:49 +0000, Daniel Drake wrote:<br>
> On 24 November 2010 22:40, Kevin Gordon <<a href="mailto:kgordon420@gmail.com">kgordon420@gmail.com</a>> wrote:<br>
> > Is this recommendation against yum and rpm for all software, or just the<br>
> > oplc repo packages, the kernel and the firmware?  I'm certainly happy doing<br>
> > just safe builds for the core.<br>
><br>
> To avoid all corner cases it the recommendation really needs to be "everything"<br>
> In reality, you'll probably get away with it, especially because<br>
> you're only really working with added packages in your deployment (not<br>
> upgrading ones that are already installed).<br>
><br>
> Some of the resultant problems will also not affect small deployments<br>
> like yours. For example, one side effect is that olpc-update pristine<br>
> (efficient) updates stop working as soon as you make any filesystem<br>
> modifications like this. Another side effect is that your<br>
> custom-installed packages will magically disappear after an<br>
> olpc-update upgrade (which in a real deployment would happen without<br>
> you even knowing).<br>
><br>
> But in a small deployment like yours, touching each laptop for updates<br>
> is probably more sensible than the knowledge and infrastructure<br>
> investment needed for hands-off olpc-update, so you aren't affected.<br>
><br>
> > However, as part of our 'refresh' stick when we wipe and install a new<br>
> > signed build, we generally also include the necessary rpm's for cheese and a<br>
> > couple of other utilities that are locally installed from the USB stick<br>
> > using a bash script; or, for the Vernier software dependencies, the<br>
> > dependent rpm's are installed by means of a python script.  However, they<br>
> > are rpm's and they are downloaded onto the stick (the first time) using yum,<br>
> > and they are then installed from the stick using --localinstall from the<br>
> > stick.<br>
><br>
> You probably won't see any problem with this collection of changes.<br>
> Nevertheless, at the SF summit I started showing Adam the "correct"<br>
> way to do this: building a custom OS image with those customizations<br>
> already included. We didn't have time to completely finish it, but he<br>
> picked it up quickly and could probably finish it with a little effort<br>
> (and perhaps a couple of mails to this list).<br>
<br>
Having os-builder required to have net access in <a href="http://ksmain.50.repos.py" target="_blank">ksmain.50.repos.py</a> is<br>
less than ideal for remote image creation. Once the cache is downloaded<br>
could we not just run createrepo on the cache and point os-builder to<br>
the local url instead of going out to the net all the time? something<br>
like:<br>
<br>
if use_cache:<br>
            url = "file:///%s/imgcreate/%s" %(ooblib.cachedir, name)<br>
        else:<br>
            url = "<a href="http://mock.laptop.org/repos/%s" target="_blank">http://mock.laptop.org/repos/%s</a>" % name<br>
<br>
Attached is a rough diff of what I have in mind.<br>
<br>
On a side note both 10.1.2 and 10.1.3 share the the same olpc repo via os-builder<br>
(<a href="http://xs-dev.laptop.org/%7Edsd/repos/" target="_blank">http://xs-dev.laptop.org/~dsd/repos/</a>), that makes it harder to tell the break<br>
between the two.  Now it's impossible to re-spin os852 without hard-coding the<br>
rpm versions elsewhere in os-builder. Just a thought.<br>
<font color="#888888"><br>
<br>
Jerry<br>
<br>
<br>
<br>
</font><br>_______________________________________________<br>
Devel mailing list<br>
<a href="mailto:Devel@lists.laptop.org">Devel@lists.laptop.org</a><br>
<a href="http://lists.laptop.org/listinfo/devel" target="_blank">http://lists.laptop.org/listinfo/devel</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Javid Alam<br>Software Developer and Technical support Officer OLPC<br>Ministry of Education<br>Kabul Afghanistan<br>contact: +93(0)798123451<br>alternative email: <a href="mailto:javid.alam@moe.gov.af">javid.alam@moe.gov.af</a> <br>