containerit icon indicating copy to clipboard operation
containerit copied to clipboard

Evaluate/discuss a container "from source"

Open nuest opened this issue 7 years ago • 3 comments

Imagine a container where everything is installed from source, and sources are kept.

Is this feasible? Does it actually add value from a reproducibility perspective? What are the expected overheads (build time, storage, ...)?

Where is the handover point, i.e. what is installes as binary. make?

nuest avatar Jun 06 '17 13:06 nuest

I have always taken the OS (+ dev layer: compilers etc) for granted; I felt comfortable knowing it is open source, but never had the need to actually look into the source code, and only installed from source when this was needed.

For R, I've looked into the R core (C) source at several occasions, and have looked at the R source code of installed and recommended packages in many instances.

edzer avatar Jun 06 '17 14:06 edzer

OK, "OS + dev layer" seems to be a reasonable level of using only binaries.

I assume you then browsed the source of R core respectively the packages online, navigating yourself to the respective version/tag. Correct?

I'm just wondering about that connection between the installed package and the actual source code. It would be very clear what the code is when it is in the container.

Note to self: To find out what is needed to build R, this might help: docker run -it --rm ubuntu:xenial apt-get update; apt-get --simulate build-dep r-base or docker run -it --rm jsmigel/centos-epel yum-builddep R

nuest avatar Jun 06 '17 14:06 nuest

I usually look at the source code of a function by printing the function in R; I'm a lazy person. And it has the advantage that the version will be right. Doesn't work for C/C++, although they now developed sth to that end.

edzer avatar Jun 06 '17 14:06 edzer