From owner-freebsd-current Tue May 7 16:59:35 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 76BC637B407 for ; Tue, 7 May 2002 16:59:29 -0700 (PDT) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g47NxOob508290; Tue, 7 May 2002 19:59:24 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200205072309.g47N9JA2001180@apollo.backplane.com> References: <200205072241.g47Mf0jV002339@grimreaper.grondar.org> <200205072309.g47N9JA2001180@apollo.backplane.com> Date: Tue, 7 May 2002 19:59:23 -0400 To: Matthew Dillon , Mark Murray From: Garance A Drosihn Subject: Re: The future of perl on FreeBSD Cc: current@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 4:09 PM -0700 5/7/02, Matthew Dillon wrote: >:3) Ditch perl from the base system completely, and rely on >: the ports system for FreeBSD's perl requirements. >: PRO: Speed up "make world", debloat source tree, prevent >: many cross-build breakages. >: CON: No high-level scripting system in the tree by default >: (need to install a port to get one). The ports >: collection will need some work to handle this. >: I've tested a build of this, including kernel. Some apps >: (like sockstat) break. I could commit this if it is wanted. > > Assuming the base utility issues can be addressed, I would > go for #3. I prefer #3 too. > If this cannot be accomplished then I would recommend > keeping an unadorned perl in the base system but calling > it something else, like resurrecting the notion of > 'miniperl' and having the base utilities that use perl > explicitly specify /usr/bin/miniperl, and not having > a /usr/bin/perl in the base system at all... kind of a > modified #3. I would also be happy with this tactic. Another advantage of this tactic is that developer who does change any of these base-system perl scripts will be forced to do it in exactly the same environment as the base system. Ie, they will not make a change which happens to work on their system only because they already have some group of libraries installed (from a port). If there is any perl in the base system, it should be one which is not AT ALL effected by any perl-related ports. The more I think about this, the more I am convinced this idea of separation is the right idea. (assuming we have any perl in the base-OS) -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message