> which is too complex to describe in this small contemplation. “I have discovered a truly remarkable proof which this margin is too small to contain.”
Regarding first workaround: You are right, package names won't collide, however package purposes will and files created on the file system will. Regarding second workaround: Indeed, this way, computer doesn't need to solve dependency constraints. A human has to. For every single package. Please let me remind you that we need package managers for humans to work less, not more. Maintainers are humans too. — Kindest regards, ¬Σ On Fri, Nov 27, 2015 at 3:09 AM, Martin Vahi <[email protected]> wrote: > > 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, > [email protected] > > > > > _______________________________________________ > nix-dev mailing list > [email protected] > http://lists.science.uu.nl/mailman/listinfo/nix-dev > _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
