DragonFly users List (threaded) for 2005-05
> > I have been keenly waiting for a decision on what kind of a packaging
> > system DragonFlyBSD will end up having. Are we going to stick with glue
> > for FreeBSD ports, switch to pkgsrc, or develope something completely
> > original?
> For myself, I'll be starting to fix the programs I use and submit the
> patches back to pkgsrc. I'm pretty sure that pkgsrc provides a framework
> on which most, if not all of the requirements, can be implemented.
> There are some parts I'm not entirely happy with, but nothing impossible
> to change.
The following scenario is the most crucial from my standpoint as a
In the future, when dfly has stabilized, I have installed release X.Y,
and used the binary packages provided. Now, there's a remote root hole
in software Z, which I'm using.
Will I have to:
(1) Give the command pkg_upgrade -r Z, and watch as new version of Z
installs, while also all Z's dependencies are automatically
(2) Give the command pkg_add -r Z, watch it whine about how it's already
installed, remove it by hand, try to install it again, watch it
whine about a dependency, remove the dependency by hand, try to
install again, etc etc etc.
(3) Get the latest pkgsrc, start compiling Z and all it's dependencies
from source, watch it take 4 hours while making the server
unacceptably slow, and finally die on a compile error because once
again one of the many package maintainers have not had infinite
amount of boxes to try compiling on.
(4) Have one separate box to build on, make my own binaries, and then
Of course, only solution 1 is acceptable, and 4, provided that the
binary building process is both trivial and automated regarding