[erlang-questions] modular otp concerns
Tue Feb 18 23:49:24 CET 2014
On Tue, Feb 18, 2014 at 6:30 PM, Björn-Egil Dahlberg wrote:
> On 2014-02-18 14:30, Loïc Hoguin wrote:
>> On 02/18/2014 12:48 PM, Tuncer Ayaz wrote:
>>> I know that at least Bjoern-Egil has been investigating the possibility
>>> splitting up otp.git into sub repos, and before anything is set into
>>> stone, I'd like to resolve one concern I have.
>> I thought he was the only proponent of this in the OTP team?
> Hi there!
> The following is my take on this.
> Ok, so a modular OTP has be talked about in a context of a package
> manager (PM). The recent revival PM discussions on this ML has me a
> bit worried. I feel it lacks focus, everybody has an idea of they
> want and starts coding. That is fine but OTP can't commit to any of
> it at this point and I'll try to iron out why. I don't have all the
> details in my head so bear with me.
> If/when we split the OTP repository, and this split should be on the
> level where we have specific versions i.e. on application level. It
> has solve the issue of easy delivery of new patches and release on
> these specific applications. Some have voiced a concern that it will
> simply be to many repos and we should instead group them, i.e. Orber
> + cos* etc. I say fine, if so then those applications should have
> one version (and be a single application). One versioned entity per
> repository thank you.
> For our customers within Ericsson, we have to be able to patch a
> specific application on a specific level (no surprise there), and
> the norm has been to build binary deliverables that is delivered in
> clearcase. Due to increasing growth of supported platforms it is now
> unsustainable to provide binary deliveries for all these platforms
> along with different build settings.
> To support source patch-deliveries and to avoid a permutation
> explosion with tags in the main otp repo with releases and patches,
> we (or atlease I) would like to split the otp repository to a
> maintainable level. The application level is extraordinary good and
> a natural one. Application versions can be tagged directly in the
> application repo without specifying some globally defined patchlevel
> on the otp repo. A split has additional benefits such as decoupled
> release cycles and streamlining otp applications to look like any
> other application. We could also setup different maintainers for
> different, traditionally OTP only, applications on GitHub. This
> could ease development for those applications.
> Applications needs to understand dependencies. I've already stated
> that we want src-deliveries and this is key. We have nifs and
> drivers that is platform dependent but even prebuilding beam-files
> might be problematic since we could have different (older) erlang
> runtimes trying to load too new code. This means we at least have
> two types of dependencies, a build dependency (or requirement) for
> building the application and a runtime dependency for running the
> application. I would like to specify these dependencies in the
> .app.src file and specify that such files needs to be interpretable
> before compiling or sedding them. Alternatively, having yet another
> file: a manifest file.
> .. now i've been interrupted too many times writing this mail ..
> What I would like to say is, OTP wants a package manager to make a
> split viable and we have to have some control of a PM to be able to
> use it for delivering patches within Ericsson. Certain requirements
> has to be met, for instance cross compilation has to work
> flawlessly, and we need to be able to specify private sources to
> private users, i.e. no central tracker. Otherwise we have to roll
> our own system. All of this will be discussed internally at OTP
> between 17.0 - 18.0, so the timing of a PM discussion on the list is
> a bit off. =)
All of the above sounds to me like we should aim to extend the built-in
.app functionality, and use that as a base for a bundled package
manager in R18. We've discussed this multiple times, but we should do
it properly and have one official tool that's used by otp.git and
external_app.git. So, your "own system" should be suitable for use by
non-Ericsson users too.
As with the other discussion, it's okay to wait for the R17 release to
happen first. The release isn't that far in the future anyway.
More information about the erlang-questions