DragonFly BSD 3.4 Released, With New Packaging System 75
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."
Excuse my ignorance (Score:2)
Re: (Score:3, Informative)
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.
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
Re: (Score:3)
I don't think most people on Debian are rebuilding their systems using apt-build. Then again I'm not most people. My boss insists there's some reason to use aptitude but whenever I try to corner him, he tells me about the use case for dist-upgrade without naming dist-upgrade, and can't give other reasons.
"apt-get will leave packages in held state"
yeah, when there's a dependency that was not previously installed, you have to use dist-upgrade to insist that apt-get installs new packages, step that's not usu
Re: (Score:3)
Re: (Score:2)
> My boss insists there's some reason to use aptitude but whenever I try to corner him, he tells me about the use case for dist-upgrade without naming dist-upgrade, and can't give other reasons.
Because, in another thread, I explained that FreeBSD pretty much _does_ make you build the packages, and to that extent GP was right, they are not the same. To compare, Debian has lots of ways that are not really different from each other for not building the packages, and you've just told me about apt-build whic
Re: (Score:2)
In summary, it's not really different, you're really just moving the location of the curtain to in front, or behind... someone had to build the distribution packages up from source, and that person was not extracting tarballs by hand.
Re: (Score:3)
Freebsd and gentoo at least also have binary package systems.
Afaict the difference is that on BSD/gentoo building from source at install time is the primary method while installing binaries is an extra. On debian installing binary packages is the primary method while building from source at install time is an extra.
Re: (Score:3)
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
Re: (Score:1)
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.
Re:Excuse my ignorance (Score:4, Informative)
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)
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.
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:1)
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.
Re:Excuse my ignorance (Score:4, Informative)
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.
Re: (Score:1)
Re:Excuse my ignorance (Score:5, Informative)
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.
Re: (Score:1)
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:1)
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.
Re: (Score:3)
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
Re: (Score:2)
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.
Re:Excuse my ignorance (Score:4, Informative)
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]
Re:Excuse my ignorance (Score:5, Informative)
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.
Re: (Score:2)
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.
Re: (Score:3)
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
Re:Excuse my ignorance (Score:4, Insightful)
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.
...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.
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:3)
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
Re: (Score:2)
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
Wait? (Score:1)
I read on Slashdot that BSD was dead. And, Netcraft proves it. So, what is this?
Re: (Score:3)
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.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Saying that something isn't a large multi-core server until it hits supercomputer scales is setting the bar a bit higher than I think most people care about. I get exposed to more leading edge hardware than most people, since I'm well known for doing database performance tuning. I see 48 core servers all the time at businesses; even my toy server at home has 24 cores nowadays. I have seen SGI Altix hardware with a very large number of cores, and most recently I had root access and some testing time on a
Re: (Score:2)
and part of the reason they got off their asses was Intel demo'd that 100core cpu. How about having 12 or more of them if they're low-power (ARM range) but full x86_64 compat?
Supports gcc 4.7 (Score:2, Interesting)
Gcc 4.8 has been totally stable for a while now, so I'm just a bit underwhelmed.
Re: (Score:2)
The summary is a bit off. They are using gcc 4.7 as the system compiler. GCC 4.8 supports BSDs just fine.
Re: (Score:2)
Yes, and interestingly, "GCC 4.4 remains on the system and still has an important role as the primary DPorts compiler."
Re: (Score:2)
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.
GNU compiler on BSD (Score:2)
Re: (Score:2)
the BSD are considering other compilers, FreeBSD going to CLang and NetBSD might go to pcc
Re: (Score:2)
Re: (Score:2)
not yet, it can compile openbsd on some architecture but I see it's still using gcc even for the new 5.3
Re: (Score:2)
ZFS, Hammer & FBSD (Score:2)
Re: (Score:1)
> 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.
Re: (Score:2)
Re: (Score:1)
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