Forgot your password?
typodupeerror
Operating Systems Upgrades BSD

DragonFly BSD 3.4 Released, With New Packaging System 75

Posted by timothy
from the diversity-matters dept.
An anonymous reader writes "DragonFly BSD has released version 3.4. This version is the first BSD to support GCC 4.7, and contains a new experimental Aptitude-like binary package installed called DPorts, which uses the FreeBSD ports collection as a base."
This discussion has been archived. No new comments can be posted.

DragonFly BSD 3.4 Released, With New Packaging System

Comments Filter:
  • But could someone explain how BSD package management compares to .rpm and .deb?
    • Re: (Score:3, Informative)

      by Anonymous Coward

      The regular package management for BSDs, the ports collection, is not like .rpm or .deb at all. The closest Linux equivilent would be Gentoo, since it was based on Ports, and improved upon from there (improved in the opinion of the people doing the improving anyway.) Everything there is compiled from source based on some pretty beefy makefiles.

      I don't know much about this new package system, but if it's based on Aptitude, it's probably better to compare it to apt-get or Yum than to .rpm and .deb.

      • by Ash-Fox (726320)

        The regular package management for BSDs, the ports collection, is not like .rpm or .deb at all. The closest Linux equivilent would be Gentoo, since it was based on Ports, and improved upon from there (improved in the opinion of the people doing the improving anyway.) Everything there is compiled from source based on some pretty beefy makefiles.

        Not like .deb at all? So how is this not like apt-build again?

        • by Yebyen (59663)

          It's actually more like, but imagine apt-build out on the front of the interface. In the newest FreeBSD pkg-ng, there are no binary packages other than a few that are able to be used for bootstrapping pkg-ng, so you are compelled to build them (with portmaster or manually mucking with makefiles in /usr/ports)

          There is a "non-ng" pkg tools set, classic pkg_add pkg_delete pkg_info etc that has many packages that you can download (would it be accurate to say most of ports tree? I don't think so), but they are

          • by Anonymous Coward

            DPorts fully uses pkgng. Actually, old tools pkg_* are not even present. pkgng is somethink like a GNU package manager. You can use pkg install, pkg autoremove etc. Dependencies are managed by the package manager.

            The policy is to keep two sets of packages : RELEASE, binaries freezed at the release time, and LATEST, were packages are updated when an update is avaible.

            Dports currently comes with more than 19 000 binary packages for both x86_64 and i386.

      • by The Moof (859402) on Tuesday April 30, 2013 @11:56AM (#43591457)

        The regular package management for BSDs, the ports collection

        The regular package management for BSDs is the pkg utilities [freebsd.org], the ports collection is a source control tree of available software [freebsd.org] that you compile yourself.

      • Re: (Score:2, Informative)

        by Anonymous Coward

        To be fair, only FreeBSD uses the Ports Collection, but also uses 'pkg' which fetches precompiled binaries and installs them and handles dependancies, which is pretty much exactly like apt and rpm. NetBSD and IIRC, OpenBSD both use pkgsrc, which also fetches binary packages, exactly like apt and rpm. All three have had this sort of package management forever.

        • by lemur3 (997863)

          openbsd allows getting a selection of each archs precompiled binaries as well as the option to build from source the entire port tree.

          some ports are available as source only, to be compiled by the enduser

      • While the topic of the discussion is about DragonFly BSD, I'd like to expand upon your broad post concerning all BSDs and "everything" being compiled from source.

        The regular package management for BSDs, the ports collection, is not like .rpm or .deb at all...Everything there is compiled from source based on some pretty beefy makefiles.

        Binary packages [freebsd.org] are also available for many ports, this is not a new thing for the ports collection or pkgsrc [netbsd.org] which is what DragonFly BSD uses [wikipedia.org]. In addition to the various formats software may be obtained from the ports collection there are various branches one may follow: unstable, stable, and release. With regards to staying up to date, FreeBSD u

    • by Anonymous Coward

      pkg_add -r has always been similar I guess. sysinstall has provided a menu for binary package installation for as long as I can remember.
      I don't know what makes DPorts special or more aptitude-like.

    • by Anonymous Coward on Tuesday April 30, 2013 @09:34AM (#43589931)

      One big difference between *BSD and most Linux systems is that a *BSD system consists of a base system plus packages. With a lot of the Linux systems, the whole system consists of packages. So for example, with a Debian system, your kernel is managed with apt thus it is managed with a package manager. In *BSD, the kernel is part of the base system.

      • Who the hell mod'ed this informative - Linux is the "base system" (you know - the kernel?) and then you pile all the other stuff on top (via packages, source, or whatever method floats your boat)
        • by fnj (64210) on Tuesday April 30, 2013 @10:18AM (#43590339)

          You missed the entire point. In BSD the kernel is not itself a package. In linux the kernel is a package just like any other package. THAT's why he is informative.

          • I get my Linux kernel as a source - that is not a "package" - there is a BIG difference between "Linux" and "distributions built on top of Linux". You absolutely do not have to use packages to use Linux...
            • Yep and it's about as usable as an LFS (linux from scratch) build is. No package manager and not much more then the damn shell (bash).

              As a gentoo user, I'm considering starting with an LFS build after converting portage from python over to pure "C" as LFS does include enough of the toolchain to build things.

              • by Tarlus (1000874)

                Well, even a distro that provides a package management system does not force you to use a packaged kernel. You can roll your own from vanilla and have it coexist happily with other pre-packaged kernels in /boot. I did this in Debian for years.

            • by fnj (64210)

              Yes, you're absolutely right. I wrote that with 99.9% of linux users in mind and avoided making the post 10 times longer than it had to be, just to be rigourously pedantic.

              The fact is, in RHEL, Debian, Ubuntu, etc, etc, etc; all the distros the vast majority of linux users use, the kernel is a binary package.

        • by Anonymous Coward

          With only a kernel, you barely can do anything. The base system in most *BSD systems consists of the kernel, some userland utilities (text editors, utilities to manage your files, etc), a compiler, X.org and other stuff. So without any packages installed on a *BSD base system, you can do all kinds of tasks already. With only a kernel (if you call that the base system), that is going to be a little bit hard, I guess.

        • by Yebyen (59663)

          No, you're wrong. The kernel is in a package and you can upgrade it via apt-get [dist-]upgrade. In FreeBSD and ilk, you have to gather up /usr/src and make buildkernel to get a new kernel. Frequently you will also want make world, which compiles the rest of the base system (think GNU toolchain, but this is definitely not GNU) that are not in packages.

          You can't really boot just a kernel without any child processes to positive effect (source?), so Linux is not the "base system" -- GNU/Linux is that. In BS

        • In most GNU/Linux distributions, "linux" is just another package, that gets updated via the package manager.
          In BSDs, the kernel (and the rest of the base system) is NOT updated via de package manager, but must be upgraded separately.

    • by Pricetx (1986510) on Tuesday April 30, 2013 @09:35AM (#43589937)

      Wikipedia has a rather well written article on FreeBSD's ports system (and being that FreeBSD has the largest user base of the *BSDs, it is often thought of as "the BSD system"). http://en.wikipedia.org/wiki/FreeBSD_Ports [wikipedia.org]

      Additionally, it may be worth noting that FreeBSD is transitioning over to a new binary package system called "pkgng", (to replace pkg_add, not ports). I don't personally know much about it, but the trusty old FreeBSD handbook has a section on it: http://www.freebsd.org/doc/en/books/handbook/pkgng-intro.html [freebsd.org]

      • by ByOhTek (1181381) on Tuesday April 30, 2013 @09:55AM (#43590139) Journal

        FreeBSD has had packages for years. It's not transitioning, it's allowing another option.

        Ports in FreeBSD, in my experience, if you follow a production-like attitude, rather than an ADD OH-NOEZ-THIS-PORT-IS-30-SECONDS-OUT-OF-DATE-MUST-UPDATE methodology, works better than any package manager I've seen (rpm, deb, yum, apt).

        The BSD package systems tend to be more like apt or yum, than simple rpm/deb. They grab your binary packages and their dependencies automatically.

        • by fnj (64210)

          Yes, FreeBSD has had "pkg_add -r" for a while to install binary packages, but it has been a poor relation to ports. They have not made available anywhere near as much in binary packages as there is in ports, they are not kept up to date as religiously, and there never was any pkg_update to give the ability to update all installed packages easily. Pkgng and an expanded binary package repo properly maintained will be fixing this.

        • by unixisc (2429386)

          In the FBSD family, there are the portsng, and then, there are the PC-BSD based PBI system. PBI is really good in that it checks for all version dependencies, and then frees up space by removing the genuinely redundant dependencies using a hash table. In fact, FreeBSD is being distributed on the same media in the same format, and even pFsense has adapted this PBI distribution.

          I am surprised therefore that DragonFlyBSD didn't choose to go with this solution. On a different note, DragonFly is still on GC

        • by Just Some Guy (3352) <kirk+slashdot@strauser.com> on Tuesday April 30, 2013 @12:02PM (#43591527) Homepage Journal

          Ports in FreeBSD, in my experience, if you follow a production-like attitude, rather than an ADD OH-NOEZ-THIS-PORT-IS-30-SECONDS-OUT-OF-DATE-MUST-UPDATE methodology, works better than any package manager I've seen (rpm, deb, yum, apt).

          My only complaint about FreeBSD ports is that, somehow or another, everything you install wants to depend on X.

          $ sudo portmaster -a
          Upgrade foo-ldap-4.3.5_1 to foo-ldap-4.3.9
          Install net/openldap24-sasl-client
          Upgrade postgresql-server-9.1.2 to postgresql-server-9.1.9
          Upgrade tcl-8.5.9 to tcl-8.5.11
          Upgrade vim-7.3.81 to vim-7.3.897
          Install X11/every-damn-thing

          ===>>> Proceed? y/n [y] n

          ...followed by bisecting to see which port wants to install the perl-tk package so it can install a config tool you'd never actually run on a production server. It desperately needs a WITHOUT_X11_I_MEAN_IT_DAMMIT=yes option.

        • by greg1104 (461138)

          Ports in FreeBSD, in my experience, if you follow a production-like attitude, rather than an ADD OH-NOEZ-THIS-PORT-IS-30-SECONDS-OUT-OF-DATE-MUST-UPDATE methodology, works better than any package manager I've seen (rpm, deb, yum, apt).

          It's manageable for a single system. The installations I've seen switch away from FreeBSD over this issue mainly cited how much effort it took to synchronize package sets on lots of machines at once. Let's say you kick off adding a new machine every week and need four of them. By the end, the odds are significant that the last system will not have the same setup as the first, given that three weeks have gone by. The actual compile time involved means that you can't even be assured that systems are ident

          • by Yebyen (59663)

            I know that it's verbodten but I do this in my personal crontab:

            4 0 * * * sudo portsnap cron update && sudo ezjail-admin update -P

            Could probably pick a better time than 4 minutes after midnight, but I'm unlikely to be upgrading ports late at night (in a jail) at that time.

            This takes 90% of the hurt out of upgrading ports. If you're not comfortable that you might want to upgrade ports around midnight, then pick a day, say Sunday, or the 30th, and make that the day. The remaining hurt is taken away

            • by greg1104 (461138)

              I would speculate that there are thousands of people who have done this type of work on most popular open systems, and some of them most certainly have dozens of machines to keep up to date.

              One of the large anecdote examples I was on the edge of was how the PostgreSQL project migrated infrastructure [postgresqlconference.org] from a heavy use of FreeBSD toward Linux. I'm not quite familiar enough with FreeBSD to comment on how many of their problems were specific to the jails structure they were using. But even with the relatively good pull PostgreSQL has for finding volunteers, we were able to find exactly zero people who felt comfortable they could solve the project's issues around package management. Switching to

    • Ports are generally small scripts that retreive source and build a binary package that is then installed.

      OpenBSD uses special Makefiles that do exactly this. The few binary packages provided are just those generated by these makefiles (only some are provided in binary form).
      Archlinux uses PKGBUILDs which are quite similar (in nature, not in syntax) to BSD's ports. While arch uses binary repositories, building a package is just a matter of running makepkg with the correct PKGBUILD file.

      Compared to rpm and de

      • by iggymanz (596061)

        OpenBSD has LOTS of binary packages,over 7000 of them installable with just a pgk_add -i

        sure, you can use ports too, but the preferred way for average user is the binary package sytem

  • I read on Slashdot that BSD was dead. And, Netcraft proves it. So, what is this?

    • by Aguazul2 (2591049)

      They have some nice ideas. The one that particularly interests me is settings up a bunch of DragonFlyBSD servers and having jobs run transparently across them, load-balancing across the cluster. This is like multi-core at the server level -- the same kind of underlying abstractions as well. Not sure if they've got it up and running yet.

  • Supports gcc 4.7 (Score:2, Interesting)

    by fnj (64210)

    Gcc 4.8 has been totally stable for a while now, so I'm just a bit underwhelmed.

    • by kthreadd (1558445)

      The summary is a bit off. They are using gcc 4.7 as the system compiler. GCC 4.8 supports BSDs just fine.

      • by fnj (64210)

        Yes, and interestingly, "GCC 4.4 remains on the system and still has an important role as the primary DPorts compiler."

    • by greg1104 (461138)

      The leading edge for what compiler is used to build the system packages lags pretty far behind current, and that's not necessarily a bad thing. To put this in perspective, right now the business mainstream RHEL6 is using gcc 4.4. It's particularly easy to rebuild your whole system with a later compiler given the ports system.

  • What is happening here? Heretics dare to use GNU code on a BSD system? Sacrilage!
    • by iggymanz (596061)

      the BSD are considering other compilers, FreeBSD going to CLang and NetBSD might go to pcc

      • by unixisc (2429386)
        I believe OpenBSD has already gone to PCC. In the meantime, Minix, which uses NetBSD userland, has also gone LLVM/Clang
        • by iggymanz (596061)

          not yet, it can compile openbsd on some architecture but I see it's still using gcc even for the new 5.3

          • by unixisc (2429386)
            The Bitrig project, which is a fork of OBSD, was initially using GCC to compile it, but has to date managed to build OBSD using LLVM/Clang. Only limitation of theirs - portability is not their goal like it was w/ OBSD, so one doesn't see legacy UnixServers like Suns being supported by it, just x86 systems
    • by idunham (2852899)

      > What is happening here? Heretics dare to use GNU code on a BSD system? Sacrilege!

      BSD has used GNU tools for ages, but most of them have lagged behind.
      FreeBSD is sticking to GPL2, which is GCC 4.2.1--but you can get a newer one from ports.
      OpenBSD has 4.2.1 and 2.95.3.
      NetBSD is the other BSD to use a GPL3 GCC, with GCC 4.5 as far as I can tell.
      MirBSD is on GCC 3.4.

      And the most fun difference: DragonFly BSD uses git as vcs, rather than cvs/svn.

      • by unixisc (2429386)
        Uh, in version 10, FBSD is fully deprecating GCC and going w/ LLVM/Clang, as is OBSD fork Bitrig. OBSD will go PCC, while Minix, which uses NBSD userland, will be using LLVM/Clang. I'm not sure what NBSD or MirBSD are planning, but the BSD guys in general are all walking away from GCC due to GPL3
        • by idunham (2852899)

          True, but surprise at a BSD using GCC (note that the OP did not mention GPL3) is not warranted by the existing conditions (note that deprecating does not mean dropping, it means stating that they intend to drop it, at FBSD 11 or later).

          Judging by the fact that Thorsten Glaser (MirBSD/MirOS developer/maintainer) is a frequent poster on the pcc-devel list, I'd guess PCC. Also, some of the other MirOS projects are in a similar vein.

          I suspect that NetBSD will use whatever compiler supports more of their archite

"Consequences, Schmonsequences, as long as I'm rich." -- "Ali Baba Bunny" [1957, Chuck Jones]

Working...