Date: Mon, 02 Nov 1998 05:02:33 -0800 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Mark Murray <mark@grondar.za> Cc: asami@FreeBSD.ORG (Satoshi Asami), mike@smith.net.au, sos@FreeBSD.ORG, ports@FreeBSD.ORG, beav@softhome.net, sprice@hiwaay.net Subject: Re: Who built XFree86 with Kerberos? Message-ID: <24159.910011753@time.cdrom.com> In-Reply-To: Your message of "Sat, 31 Oct 1998 17:24:16 %2B0200." <199810311524.RAA00776@gratis.grondar.za>
next in thread | previous in thread | raw e-mail | index | archive | help
[-current culled; too many mailing lists again] > How about breaking the ports collection into pieces, or at least > breaking away large chunks. Various people have now approached me on the topic of package generation, so I thought I'd reply to all of you en-masse rather than sending individual replies to everyone and wearing my fingers off. Hope you understand, and thanks for stepping forward with your offers of assistance. First, though I like the idea of doing package building in a sort of "distributed.net RC5 crack" style for technical reasons, I have to say that the security implications of doing it that way are very scary. As all of you know, even a very mildly trojan'd package can easily destroy your entire system and all it would take would be one back-doored copy of BitchX, submitted by someone whom we really didn't know and built under circumstances where even the _submitter_ might not know what's going on (build system gets hacked), to give the cracker community free shell accounts for life. When I said that we might want to automate the process, what I really meant was that we'd have one or more package building machines which were reasonably secure and running a package-on-demand script of some sort which detected whenever new packages entered the tree. The only human intervention would occur when a port failed to package properly, that being something that we'd probably want to know in a timely fashion anyway, by one or more "package custodians." When release time came around, I in turn would just add scooping off and "bundling" (into ISO image sized chunks) the packages to my automated release building process and this piece of the puzzle could finally have some firmer scheduling put around it. With every previous release, you see, I've never known just how long it was going to take to get packages for the CD images, and it has indeed been a delaying factor for several of them. To be fair, I've also not yelped too loudly about it since I've always been able to put such delays to good use in applying last-minute tweaks to the installation as the first serious flood of installation reports started coming in. Still, there are more FreeBSD products now and this kind of slippage in installation or package bits is probably a rapidly receeding luxury of the past, to say nothing of the day when the packages collection was actually small enough to be handled without significant automation. Steve Price, despite being somewhat self-deprecating about his efforts, also provided quite a good start to this with his code for determining just how many ports or packages would fit on a given CD image (given the potential presence of other bits on it) and where the "dependency clusters" were. With a bit of polishing and some additional code for prowling /usr/ports on a nightly basis for new package builds, I think it could work. Heck, I'll even go drive shopping tomorrow just so that bento and paddock can have enough storage to make prototyping something like this easier. Satoshi's been asking for awhile anyway, and another promised upgrade didn't happen when somebody else grabbed the drives I'd hoped to allocate to it (grrr). The other possibility I see, as I mentioned before, is that this turns out to be too much for automation and a "human touch" is required at the controls at all time in order to turn out really good packages. Since that's also too much to expect of a volunteer on an ongoing basis, if we decide that's the only way to go (and I'd prefer to try the automation approach first, if only to have definitive proof of this), then let's start talking about hiring someone to do it. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?24159.910011753>