DragonFly kernel List (threaded) for 2007-03
Re: Patch framework
On Wed, March 21, 2007 1:23 pm, Simon 'corecode' Schubert wrote:
> I don't think this is a good idea. When using pkgsrc, we are dependant on
> it. They update a package and it happens not to work with dragonfly,
> we're screwed. Additionally, there is no backlog of old packages (except
> with CVS tags maybe), so old releases could break. All in all a horrid
> idea to me. Third party software maintenance isn't really soo much of an
> issue for us, and if it is, we'll have to stick to it (compare: gcc, etc).
I already pitched my little fit about this on IRC, but here's a retelling:
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.
These arguments sound like the arguments people make against closed source
- this is not the case. It's an open source project - we can submit
packages and even get commit access, if we needed to change things. Joerg
and Jeremy C. Reed already have access, for that matter.
We have 6,000+ packages available to us; it seems silly to refuse use of
any of it because there's a chance it could break in a short-term and
totally fixable way. gcc may not be so great to bring in, but heck:
sysutils/file? lang/nawk? archivers/bzip2? net/tcpdump? There's
plenty more that we could use that are much less likely to have
compilation issues than gcc. /contrib is like a third party software
management system minus the management part.
nrelease already can add packages pretty easily; the mechanism is there
and we just need to use it.
Also: we can save binary packages to match old releases. We're already
doing that somewhat involuntarily in the nrelease framework, as last time
I tried it, it pointed to old pkgsrc binaries to build the installer.