DragonFly kernel List (threaded) for 2007-03
Re: Patch framework
:We're already dependent on pkgsrc. Not so much that we couldn't build a
:system without it, but not having some sort of third-party packaging
:system would make DragonFly a lot less useful. If the people who work on
:pkgsrc somehow decided to do something that broke pkgsrc on DragonFly,
:we'd have to look for an alternative anyway.
I don't think the pkgsrc dependance is an issue. I mean, for all intents
and purposes our current contrib/ scheme is nothing more then a snapshot
of some piece of contrib code anyway. How does this differ from
keeping a binary package around? We would distribute these binary
packages in binary-package-form as well as pre-installed on the
distribution CD, and we would also copy them onto the hard drive as part
of the installation process.
Thus a system operator would always have the ability to reinstall the
prebuilt packages without having to rely on a fresh pkgsrc build.
It would be no more error prone then contrib snapshot methodology we
use now, in my view. It would require less upkeep and it would also
give people running older systems the opportunity to upgrade portions
of those systems (e.g. sendmail, bind) from pkgsrc without having to
worry about build tree interference.
The nrelease build already does something like this... it expects certain
binary packages to be available and if they aren't it tells the user how
to get them. In the case of nrelease, I pre-build the binary packages
and put them on the DragonFly master site. Everyone who uses nrelease
is dependant on those packages to some degree.
What I propose is a slightly more sophisticated solution for
buildworld/installworld. Instead of maintaining the packages on a
master site, have buildworld maintain them somewhere (e.g. in /usr/obj),
and give it the ability to either retrieve them from the master site or
to build them from scratch (including creating the appropriate package
building environment to be able to do so without effecting the
currently running system). As long as the ABIs do not change, you
would not have to rebuild these packages every single time you run a
buildworld... the default would be to use the ones that already
exist unless an option is given.
Believe me, I have the same jitters over building packages from source
as any other person.... but those jitters do not extend to binary
packages. Once built, a binary package is a very stable entity. The
fewer dependancies it has, the more stable it is. I can safely say
that the binary packages we are talking about do not have very many