(moving dev-b2g to Bcc to avoid spamming) > Yeah, thats a good point.
There are a few caveats with building as a user, please see https://github.com/jankeromnes/dockerfiles/blob/master/firefox.docker#L8-L12 . >> Currently, your `apt-get update` can remain cached with older package refs, which could break subsequent `apt-get install`s. > > Care to elaborate, I dont fully understand. Sure. RUN instructions are cached by docker. The first time you built your image, the `RUN apt-get update` line was executed and then cached, like the following lines. If later, you modify a `RUN apt-get install ...` line and rebuild the dockerfile, docker will reuse the cached result of `RUN apt-get update`, but then, when it will try to execute the new `RUN apt-get install ...`, your system image might have out-dated apt packages links, and the `apt-get install` can fail to find the proper packages. This happened to me last week. The solution is to always write your RUN instructions with an `apt-get update` before your `apt-get install`, so that they're cached together (e.g. `RUN apt-get update && apt-get install foo bar`). Official docker images are built with massive RUN one-liners, but in your case it might make sense to have to separate `RUN apt-get update && apt-get install ...` lines. > I want to keep the container only for build purposes. Hack on code in Emacs locally, and just build in the container. Ah, I understand your use case. In the future (once I figure out how to make a container push things to USB devices) I might write a very similar dockerfile for B2G that does all the bootstrapping and building, in order to automate that process. On Mon, Sep 15, 2014 at 3:13 PM, Simon Johansson <[email protected]> wrote: > Thanks for the feedback! > > > > I'd suggest you don't build as root in your container, but create a user > instead. This avoids build side effects, weird permissions and security > issues. > > Yeah, thats a good point. > > > - It's better for caching if you put as many `apt` commands into the > same RUN instruction. > > So you mean moving the packages from the second apt run into the first? > > The reason why I did not end up doing this was because the first apt is > packages specified from the wiki, and the second line is for stuff missing > from the bare-bone 14.04 image(that I assume would most likely be installed > in case of having a desktop installation). From a maintenece perspecive it > easier, from a caching perspective it is indeed a bit stupid. :) > > > Currently, your `apt-get update` can remain cached with older package > refs, which could break subsequent `apt-get install`s. > > Care to elaborate, I dont fully understand. > > > Also, wouldn't it be better if steps 2, 3 and 4 are merged into your > dockerfile? > > I want to keep the container only for build purposes. Hack on code in > Emacs locally, and just build in the container. > > This way its usable for anyone right away, no need to get into the > container and checkout the appropriate tags etc. All you need to do is cd > into your workspace which will already be setup for the task you are workin > on and hack away, and build in a controlled environment. > > Again, thanks for the feedback. :) > > > > On Mon, Sep 15, 2014 at 2:02 PM, Jan Keromnes <[email protected]> wrote: > >> Hi Simon, >> >> Thanks for that! I was about to get into something similar for B2G. >> >> Regarding your dockerfile: >> - I'd suggest you don't build as root in your container, but create a >> user instead. This avoids build side effects, weird permissions and >> security issues. >> - It's better for caching if you put as many `apt` commands into the same >> RUN instruction. Currently, your `apt-get update` can remain cached with >> older package refs, which could break subsequent `apt-get install`s. >> >> I tried to respect these kinds of best practices in dockerfiles I wrote >> for Firefox and Chromium [1]. >> Also, wouldn't it be better if steps 2, 3 and 4 are merged into your >> dockerfile? >> >> [1] https://github.com/jankeromnes/dockerfiles >> >> >> >> On Mon, Sep 15, 2014 at 12:20 PM, <[email protected]> wrote: >> >>> Hello! >>> Yesterday I wanted to try to build B2G for my Nexus 4, and quickly >>> discovered that doing so for Arch is quite hacky[1] so I decided to build a >>> Docker image for the task based on Ubuntu 14.04. >>> >>> I have only tested it for Nexus 4 so I would imagine that lots of deps >>> are missing for other platforms(please send a PR[2] :) >>> >>> If you want to try it out its simple as >>> 1. Having docker installed and properly working >>> 2. git clone https://github.com/mozilla-b2g/B2G.git >>> 3. cd B2G >>> 4. ./config.sh device-name >>> 5. docker run -v $PWD:/B2G -i -t simonjohansson/b2g-build >>> >>> After this you should have the neccecary >>> ./out/target/product/mako/{boot.img,system.img,userdata.img,recovery.img} >>> neccecary to flash your target. >>> >>> I hope this is helpful for someone! >>> >>> [1] >>> https://developer.mozilla.org/zh-TW/Firefox_OS/Firefox_OS_build_prerequisites#Arch_Linux >>> [2] https://github.com/simonjohansson/B2G-build >>> _______________________________________________ >>> dev-b2g mailing list >>> [email protected] >>> https://lists.mozilla.org/listinfo/dev-b2g >>> >> >> >
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
