From owner-freebsd-ports Sun Sep 27 07:17:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA03990 for freebsd-ports-outgoing; Sun, 27 Sep 1998 07:17:12 -0700 (PDT) (envelope-from owner-freebsd-ports@FreeBSD.ORG) Received: from lion.plab.ku.dk (lion.plab.ku.dk [130.225.105.49]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA03982 for ; Sun, 27 Sep 1998 07:17:08 -0700 (PDT) (envelope-from tobez@lion.plab.ku.dk) Received: (from tobez@localhost) by lion.plab.ku.dk (8.8.8/8.8.8) id QAA27506; Sun, 27 Sep 1998 16:16:56 +0200 (CEST) (envelope-from tobez) Date: Sun, 27 Sep 1998 16:16:56 +0200 (CEST) Message-Id: <199809271416.QAA27506@lion.plab.ku.dk> From: Anton Berezin To: croyle@gelemna.ft-wayne.in.us CC: ports@FreeBSD.ORG In-reply-to: <86g1deo61r.fsf_-_@emerson.gelemna.ft-wayne.in.us> (message from Don Croyle on 26 Sep 1998 17:36:16 -0500) Subject: Re: Why p5- ports are good CC: tobez@plab.ku.dk X-Mailer: GNU Emacs 19.34.3 Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Don Croyle wrote: > Anton Berezin writes: > > Probably I missing something very much, but I cannot help wondering > > why on earth FreeBSD ports collection has such an _enormous_ amount of > > p5-thingy ports? > The p5- ports are nice to have around because: > There are a few that really do need patching. Those can happily stand where they are, can't they? >From 97 (approximately, I did not remove duplicates) p5-thingy ports those containing patch-xx are (I commented the nature of some patches here): ./databases/p5-Pg/patches/patch-aa path tweaking ./devel/p5-Curses/patches/patch-aa default library ./devel/p5-Include/patches/patch-aa ?? ./devel/p5-IniConf/patches/patch-aa ?? ./devel/p5-ReadLine-Gnu/patches/patch-aa -L, -I ./lang/p5-Tcl/patches/patch-aa paths, libs ./net/p5-Net/patches/patch-aa --interactivity ++silent install ./net/p5-SNMP/patches/patch-aa path tweaking ./net/p5-SNMP/patches/patch-ab ?? order of args? ./security/p5-Authen-Radius/patches/patch-aa path tweaking ./security/p5-Authen-Radius/patches/patch-ab path tweaking ./security/p5-Authen-Radius/patches/patch-ac --autoload ./security/p5-PGP/patches/patch-aa name tweaking ./www/p5-Apache/patches/patch-aa ?? ./www/p5-CGI_Lite/patches/patch-aa ?? ./x11-toolkits/p5-Gtk/patches/patch-aa name tweaking ? perl -> perl5 ./x11-toolkits/p5-Tcl-Tk/patches/patch-aa path tweaking, libs versions > It allows dependencies to be installed automatically. In > addition to the p5- ports that depend on other p5- ports, we've > got p5- ports that depend on other ports, and vice versa. This is definitely very important. And now I cannot think of a better way to deal with the problem, for perl modules usually don't care about required libraries, even in cases of mere wrappers to those libraries. *sigh* MakeMaker _loves_ to say ``Note (probably harmless): library libabsolutelyimportant not found''. ;-) However I cannot name the ports collection as it is to be very intelligent when it deals with perl-related dependencies. The striking example I can mention was when I installed a port completely unrelated to perl (sorry, don't remember which one) which happened to use perl in order to produce some docs of itself. That time I already had 5.005_02 installed from perl distribution. To my horror, the port happily began to install 5.004_04; all that was actually needed was _some_ perl5, and the port failed to recognize I already have one. Luckily, perl was the only dependency of the port, so I asked it to build itself without any dependency considerations... > Pkg_delete works. The uninstall target that perl's MakeMaker > module writes doesn't. Yep. Does anybody know the reason _why_ uninstall target in MakeMaker's generated makefiles is deprecated? It looks like MM_Unix has some reasons to believe that .packlist is likely to be incorrect. But why? It really seems to be necessary to keep current bunch of p5-thingy stuff in ports collection. And that's a pity. Sorry for making the waves about this, I simply think the current way is somewhat counterproductive. Personally, I always use CPAN for installing perl things; never bothered about deinstallation, though. -- Anton Berezin The Protein Laboratory, University of Copenhagen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message