SCIENTIFIC-LINUX-USERS Archives

February 2015

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Brett Viren <[log in to unmask]>
Reply To:
Brett Viren <[log in to unmask]>
Date:
Mon, 2 Feb 2015 10:37:05 -0500
Content-Type:
multipart/signed
Parts/Attachments:
text/plain (2568 bytes) , application/pgp-signature (184 bytes)
Yasha Karant <[log in to unmask]> writes:

> On 01/30/2015 10:32 AM, Brett Viren wrote:
>
> The application, say A, runs under environment (OS) X, not environment
> Y.  One wants A under Y.  The target is Y.  Can one build A under Y
> using the appropriate "chunks"
> from X with Docker, or does one re-build ("dockerise") A under X for
> target Y?  In the first event, one only needs to be running Y; in the
> second event, one needs to be running X to build for Y.

I guess there are many approaches.  I can think of at least these:

1) Build fully static A under X and use Docker to set up target Y just
so that you can test that A works.  End user doesn't know about
Docker.

2) Build A under X, A' under Y, A'' under Z (maybe static, maybe shared)
and distribute A, A', A''.  Use Docker simply to provide convenient
build platforms X, Y, Z.  End user doesn't know about Docker.  (This is
my approach).

3) Build A in an "X" Docker image and distribute that entire image as a
binary "executable Docker container".  End user is required to have
Docker on the target Y to run the image but doesn't otherwise care what
is in the image - that is, running the image appears to just be an
executable.  This is a "heavy" solution but if application A is huge, it
might be a practical way to go.

4) As (3) but, for whatever reason, the user treats the image as an open
box and exec's a shell instead of exec'ing the application.

> Presumably, any application that will run under CentOS, in particular,
> CentOS 7 that is the RHEL source release for other ports, such as SL
> 7, should be able to run under SL.  

It depends.  As you first asked in this thread, any required shared
libraries need to be available and compatible.  If the application
exec's any external executables they obviously need to exist.  Likewise,
if the application loads Python or other interpreters then there may be
some modules required.

> My understanding is that SL 7 is
> not built from the actual RHEL 7 source that is used to build RHEL 7
> that is licensed for fee, but from the RHEL packaged CentOS source
> (CentOS now effectively being a unit of Red Hat, a for-profit
> corporation) that is used to build CentOS 7 (that, as with SL 7, is
> licensed for free as a binary installable executable system that
> requires no building from source per se).

I'm not a lawyer and quickly am underwater when it comes to licensing
details.  

All I (think I) know is that if someone gives me a binary distributed
under the GPL, they must provide me on request the source code with
which I may do as I please (consistent with the GPL).

-Brett.


ATOM RSS1 RSS2