[erlang-questions] modular otp concerns

[Tuncer Ayaz]

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
>>> of
>>> 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.