On Fri, Jul 29, 2016 at 3:34 AM, Antti Kantee <[email protected]> wrote: > 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) >
In general I'd agree about having a single "configuration", but I believe it settles down to how rumprun-packages is viewed eventually. There are two way to look at rumprun-packages: 1. rumprun-packages a unique target system and needs to be built completely (as a whole). 2. rumprun-packages hosts set of recipes, which eventually build different target system (based on the recipe). Note that one recipe can depend on another - say Erlang depends on libressl or openssl. I favor the second approach and hence suggested sub-folder within rumprun-packages/erlang for Erlang release based recipes rather than in the base folder. The rumprun-package snapshot or rev ties with an eventual target system but all the recipes need not be built together (unless for maintaining the sanity of the overall package). In the absence of an elaborate design (which I thought I'd do but couldn't spend much time on) take a look at an interim arrangement (at https://github.com/neeraj9/hello-erlang-rump) to highlight the point I am trying to make here. My "hello-erlang-rump" repo (apart from couple of others) has Makefile.rumprun which gets included in base Makefile and builds everything from scratch which is required but just Erlang from rumprun-packages (rather than build python3, etc which is not required anyways). The demo package is not yet complete but does get the basic work done to larger extent. -Neeraj
