1. 8
  1.  

  2. 4

    This is by the author of Synth who was kicked out of the FreeBSD ports community in a storm of controversy. While I don’t know anything about Ravenports I wish this effort would be spent on making Nix more universal. Or at least implementing Nix in something other than a hot mess of C++ code. And I hate manifest files, why can’t the package manager figure that out for me on install!??!

    1. 3

      I guess this is John’s way to make Nix more universal :) Developing dports and retiring pkgsrc moved DragonFly a big step forward.

      1. 1

        Would you have any links to the discussion(s) surrounding the switch from pkgsrc to dports? I’m curious about the details.

      2. 2

        Wait, what?! I just knew him as a long-time dports maintainer in DFly, had no idea he had since been kicked out of the FreeBSD ports. I guess I missed another layer of controversy in *BSD!

        For how relatively small all the *BSD projects are, and being all volunteer-based effort, it’s quite amazing how often folks get ‘fired’ from the various projects. Curious — does it happen in the Linux world as often?!

      3. 2

        “ GCC 7 must be available on the platform, and must include fully functional C++, Fortran and Ada front-ends. For exotic platform/architecture combinations, this may require cross-compilation bootstrapping along with new support patches to bring Ada tasking capability to the candidate platform. “

        Ada? I never see it in FOSS projects. How does Ada tie into this?

        1. 6

          The ravenadm tool is written in Ada.

          1. 1

            Oh, that makes it even better. Thanks!

          2. 2

            I’m more … intrigued? curious? horrified? by the dependency on FORTRAN.

            1. 6

              Nothing in Ravenports depends on Fortran. Ravenports has a single “ports” compiler that it provides. It does not use the host system’s compiler. So Fortran front-end is needed to build fortran-based ports. Same with Ada, but in that case it’s needed for self-hosting because the admin tool is written in Ada.

              Those familiar with the clang/gcc and libc++ vs libstdc++ mess vs ports compilers mess in FreeBSD ports will appreciate the “one compiler” approach of Ravenports. It solves a lot of problems.

              1. 3

                Dammit, that makes far too much sense. I was sort of hoping it used some hyper-optimized LAPACK based dependency resolution algorithm.

                1. 2

                  Since I ranted a bit in a thread about wishing the effort put into this was put into the Nix package manager, could you speak a bit to why you chose to make Ravenports rather than try to make something like Nix more accessible? A “ports are what I know” answer is perfectly acceptable as well. And, to be clear, I’m not saying Nix is the end-all-be-all answer, just that I’d much rather see things a lot more like Nix than rebuilding aspects of it, as they usually end up being unprincipled and broken in the long run.

                  1. 2

                    But aren’t you in effect implying that the Nix manager is the true solution, or at least has the potential to be? I was aware of Nix manager and its basic premise. It’s implementing a unique concept that the author felt was the right approach. Ravenports is the same case; I felt my approach, which is also unique, is the way to go. The two concepts are not compatible. Plus if it’s really written in C++, that’s not something I’m inclined to contribute to. Already Ravenports on Linux is a single repository for all distros. Does a Nix package repository work on all distros too? (assuming glibc-based for both here).

                    Finally, I’m not providing a “package manager”, I’m providing the packages. Those packages can be built to support other package managers. It’s possible (I’m reserving judgement until I understand the nix package structure and how nix works internally) to have ravenports build packages that the nix manager could manipulate.

                    1. 2

                      I think the solution Nix has is right, it just solves a lot of common problems very well. Like allowing anyone to install software without being root, allowing multiple versions of software to exist concurrently, even changing the versions based on what directory you’re in right now, and seamlessly allowing binary and source builds. Nix is also the easiest package manager I’ve found to get contributing in. It is a big ball of terrible C++ which is why I don’t think starting with Nix as it exists now might be the right way to go but rather taking the idea and providing a better implementation. I’ve used Nix on NixOS and OS X and it worked fine in both. It even comes with it’s own defined compiler version as it seems Ravenports does.

                      Ok I did not realize Ravenports was basically a translation layer between packages and the underlying package system, I guess that means it handles coexisting with the native package management on the system better? How do things like sub packages and supporting multiple versions of software work in Ravenports, then, if it is dependent on the underlying package system for the heavy lifting, or am I misunderstanding you? I poked around the documentation a bit but I didn’t stumble upon answers to these questions. If I just missed it, happy to read a link if provided. Thanks.

                      1. 1

                        It’s not a translation layer. The software is built from instructions it provides (no “underlying.package system” is used). It then has to be packaged. Each package manager has a defined structure and compression packages it handles. Right now ravenports only knows one package format. It is feasible to allow different package formats (selectable). The building portion before it stays the same.

                        regarding the rest:

                        1. There are some packages its simply impossible for a non-root user to install based on what has to be installed. Therefore non-root use is limited (and the limits kick in sooner than you think from the little I’ve played with it)
                        2. Ravenports ports would allow 1 version per repository, but multiple repositories can exist simultaneously. This would satisfy requirements in a professional setting (e.g. one server requires one set of s/w, another one has version requirements which are distinct). The only way to have concurrent versions would be to copy the build instructions and modify it with a different name and location. That’s not what you mean though.
                        3. as ravenports will be published as a whole on a weekly basis, source and binary package mixing are also “seamless” although the need for doing it is way reduced. I don’t think people would use this advantage much.

                        since users don’t care what something is written in, how come Nix package manager didn’t take off independently on other platforms?

                        1. 1

                          There are some packages its simply impossible for a non-root user to install based on what has to be installed. Therefore non-root use is limited (and the limits kick in sooner than you think from the little I’ve played with it)

                          This has not been my experience. A lot of software a user wants to use is not special in any interesting way that requires root. As a developer, I sometimes just want a specific version of a library installed to test something without it affecting my whole system. Being able to push my dotfiles into the package manager is also quite nice, it unifies quite a bit. These things not only don’t require root but one explicitly does not want them to be global.

                          since users don’t care what something is written in, how come Nix package manager didn’t take off independently on other platforms?

                          I don’t know? Why don’t more people use FreeBSD or DragonflyBSD? I’m a really terrible judge of why people choose their technologies as it rarely makes sense to me.

                          1. 1

                            This has not been my experience.

                            I’ve maintained literally thousands of ports. I bootstrapped gcc on FreeBSD-ARM64 without having root access. I know first hand there are many critical ports that can only be installed by root. I didn’t say every package or even the majority require root access. but the ones that do are critical, rendering user-built and install package capability basically useless in several use cases. Trust me, I have experience in this area.

                            I don’t know [about lack of nix pm uptake]

                            Cream doesn’t always rise to the top, but it often does.

                            1. 1

                              Do you have any specifics for what you mean by installed-per-user packages being problematic? I think I’m just too ignorant of packaging projects to understand exactly what you’re referring to as I haven’t had nearly as much experience packaging ports as you. While I use FreeBSD now, I did run NixOS for awhile which is the whole OS based on Nix and did not run into any issues with user-specific packages. Maybe someone like @grahamc knows what you are referring to and can speak more specifically to that.

                2. 2

                  Good point lol. I wonder what the story is on that. Better be highly-optimized libraries and/or parallel versions for use of this tool in HPC applications. Ravenports for supercomputers. That would be neat.

                  EDIT: Saw this in distrowatch:

                  “The Ravenports have major technical advantages over FreeBSD ports such as: variant ports (similar to OpenBSD flavours, replaces FreeBSD master/slave ports). Sub-packages (ports can create one or more sub-packages, e.g. you can load just a Fortran runtime library instead of pulling in the entire GCC). “

                  Maybe just to support existing Fortran code in projects.

              2. 2

                Is it just me, or are those special slide effects really annoying?! I think I’ve seen ’em before, too

                1. 2

                  No, I found it pretty annoying as well, especially on mobile. It’s just unnecessary glitz.