On 26/07/16 15:12, Neeraj Sharma wrote:
I've been thinking about this for a while but delayed it due to my overambitious attempt to think about a different packaging mechanism before bringing it up. Although I have not completed that attempt yet but need a way forward for the time being. The idea is to support multiple releases of packages within the rumprun-packages (say for Python, Erlang, Go or any other). The current scheme (directory structure) supports just one of the release at a time, while practical use cases would require more. I am starting to believe a simplistic approach (see below) should suffice for the time. I am going to take Erlang as an example within the rumprun-packages, but it will be same for any other package as well.rumprun-packages > Erlang > {Erlang-17, Erlang-18, Erlang-19, ...} The "rumprun-packages > Erlang > Makefile" would build the stable release (by choosing one of the subdir) of any one of the available revisions or custom version based on the package maintainer, while allowing any other build based on environment variable. This scheme would additionally allow non-standard builds of an application for cutting-edge-prototyping which needs to be maintained for greater good (like a few I have been thinking for Erlang).
Hmm, this proposal sounds isomorphic to the system already in place for {libre,open}ssl. What's the benefit of additional directories?
I'd also argue that one rumprun-packages "configuration" should be used for building exactly one target system. That automatically does away with conflicts and other similar problems that normal packaging systems must solve. Beyond Rust, the build cost for a target system is cheap enough to just build everything in bulk without having to worry about reusing binaries. I'm not sure what to do with Rust, though. Maybe it's some sort of special case that we should not optimize the common case for (cf. Hints for Computer System Design)
