[Nix-dev] Design Patterns for Achieving what Nix is Advertized for

[Martin Vahi]

In the light of the instability of the Nix

https://github.com/NixOS/nix/issues/718

I started to think, if it is possible to achieve
the same goals without using the Nix. Could someone
please comment, if there is something that
the Nix offers and the solutions described
here by me do not offer? Comments on flaws
within the described desing patterns are also welcome.

Nix sales argument:
    Multiple versions of the package can
    be used simultaniously and each of the
    packages can use its own set of dependencies.

Proposed workaround design pattern:
    Each version of the package is published
    to a traditional Debian/RedHat packaging
    system under its own name, id est the
    version of the package is part of the
    package name. There exists a specially
    named package that always references
    to the newest version, something
    along the lines like

        gcc_newest

   Different versions would be:

        gcc_v_4_9_CPUFAMILY_x86_CPUSUBTYPE_i386_SOFTWARECONFIG_1
        gcc_v_4_9_CPUFAMILY_x86_CPUSUBTYPE_i386_SOFTWARECONFIG_2
        gcc_v_4_9_CPUFAMILY_x86_CPUSUBTYPE_i486
        gcc_v_4_9_CPUFAMILY_x86_CPUSUBTYPE_i586
        gcc_v_4_9_CPUFAMILY_x86_CPUSUBTYPE_i686
        gcc_v_4_9_CPUFAMILY_arm
        gcc_v_4_9_CPUFAMILY_AMD64_SOFTWARECONFIG_1
        gcc_v_4_9_CPUFAMILY_AMD64_SOFTWARECONFIG_2
        gcc_v_4_9_CPUFAMILY_MIPS

        gcc_v_4_8_CPUFAMILY_arm_v6
        gcc_v_4_8_CPUFAMILY_arm_v7
        gcc_v_4_8_CPUFAMILY_x86_SOFTWARECONFIG_1
        gcc_v_4_8_CPUFAMILY_x86_SOFTWARECONFIG_2
        gcc_v_4_8_CPUFAMILY_x86_SOFTWARECONFIG_3

   The package names would actually conform to a
   small domain specific language(DSL) with its own
   syntax and semantics, which is too complex
   to describe in this small contemplation.
   The DSL would require that packages with
   different names do not collide by their
   package name meaning. Id est only one of the
   following 2 names would be allowed:

       gcc_v_4_8_CPUFAMILY_x86_SOFTWARECONFIG_1
       gcc_v_4_8_SOFTWARECONFIG_1_CPUFAMILY_x86

   (The implementation might be simplified so that
   the package names are generated by a
   helper Ruby script, where people just "fill in forms".
   The Ruby script acts as a primitive "formal verifier"
   for the DSL.)


A remark:
    As of 2015_11_27 it seems to me
    that that kind of design pattern
    has been already widely implemented.
    Not with so much detail, but that's a
    matter of rigor at the part of the
    package maintainers, not that the
    Debian/RedHat packaging system would
    limit the use of that design pattern.

    If everything were packaged with such rigor,
    then very specific dependencies could be
    declared for every package. What regards
    to the idea that it might be laborious to
    create a separate package for every CPUFAMILY
    CPUSUBTYPE, then like it or not, as it turns out

    https://github.com/NixOS/nix/issues/84
    https://github.com/NixOS/nixos/issues/66


    in practice, that's a job that has to be
    done anyway, specially at the testing side.
    The naming scheme just shows the vastness of
    the actual task.



Nix sales argument:
    It is possible to select, what packages
    are available in the environment(PATH, libs), the
    environment is versioned(allowing rollbacks, branches, etc.)
    and the environments are reproducible on
    different computers by having the clone computer
    go from state 0 (the "hello" has been installed)
    to the destination environment state by
    going through all those state tree vertices
    that are on the path from the root (the "hello")
    to the leaf or some vertex in between.


Proposed workaround design pattern:
    Package all software so that the

        <package folklore name like the gcc>_newest

    is never referenced at any build script.
    In that situation the walking of the state tree
    looses its point, because the task of achieving
    a state reduces to satisfying the dependencies
    of the state. Dependency graph regions that do not depend
    on each other and have their common dependencies
    met, can be built/compiled in parallel,
    at different operating system processes, may be
    even on different computers.


So, thank You for reading this long letter and
the question is, what am I missing, where am I mistaken?


Curiously and from a position of a heretic,
Martin.Vahi at softf1.com



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20151127/f03e42b0/attachment-0001.bin