Date: Fri, 5 Jan 2001 04:08:28 +0100 From: Anton Berezin <tobez@tobez.org> To: freebsd-ports@freebsd.org Cc: Alex Kapranoff <alex@kapran.bitmcnit.bryansk.su>, Christopher Masto <chris@netmonger.net>, Clive Lin <clive@CirX.ORG>, Josef Karthauser <joe@tao.org.uk>, Neil Blakey-Milner <nbm@mithrandr.moria.org>, Sheldon Hearn <sheldonh@uunet.co.za>, Tony Finch <dot@dotat.at>, Vivek Khera <khera@kciLink.com>, Will Andrews <will@FreeBSD.org> Subject: CPAN ports: a sketch of a solution [long] Message-ID: <20010105040828.A26011@heechee.tobez.org>
next in thread | raw e-mail | index | archive | help
Hi, Here is a proposal of the solution for the much debated issue with the existing multitude of Perl-specific ports. There were many views presented and valid points raised both on cvs-all and on -ports. So here I tried to adopt some of the ideas expressed by the previous posters. I took a liberty to Cc: this to all the people who took part in the discussion. My apologies if it will annoy any one of you. First, there goes a bit of analysis of comparative advantages and disadvantages of two extreme approaches: FreeBSD p5 ports as they are implemented now, and the use of the CPAN module. Then there goes a proposal per se. The big advantage of ports collection over the use of CPAN that I believe was not mentioned before is the warm and fuzzy feeling of *support* ports create. And it is not just a feeling. There is something real in it. If you use CPAN to install a particular module, you might get lucky and have it operational right away. Or you might not be that lucky. That depends. The module might originally be written in an environment very different from FreeBSD, and require specific FreeBSD patches to work, trivial or otherwise. The module might not work at all with the particular version of Perl your FreeBSD installation has. So there are two ways to deal with this situation for a user: to fix it or to give up. And let me remind you that not every user in need of a particular module is an experienced Perl developer, and many are not even developers at all. Heck, I know some people out there who occasionally use Perl and who do not even know what `CPAN' is! Here the argument comes close to already mentioned convenience of having to deal with just a single packaging system. Even experienced developers might not want to waste their time fixing a module build; they often have better things to do. Using the ports collection, however, brings a different dimension to this. When you use a p5 port it is a fact (or as close to a fact as you can get in the real world) that at least one person had successfully built this port on your version of FreeBSD in the past, tested it and made sure it works fine. If it breaks there is someone to blame, and this is a good thing. And please don't tell me `blame the module author'. This does not work, you always have a chance to get `what this free DSB is?' in response. Furthermore, CPAN.pm cannot deinstall modules it installed. The importance of this is not to be underestimated, and the argument that it is possible to do it by hand using packlist as a helper kinda destroys the whole point of using port collection for anything. [Here I censored out few nasty ad absurdum examples; the readers are no doubt quite familiar with a concept of task automation :-)] One of the good things about CPAN is that it is by default sticks to the most recent versions of the modules, while a given port must be manually updated when a new version of a module becomes available. There exist downsides of this `the newer the better' policy, of course. I was quite astonished when I tried to install some random module with CPAN.pm as it happily proceeded to install the latest and greatest version of Perl itself! [Some of the other problems with adopting this approach are discussed later] Because of all this I think it is clear that the approach `get rid of these stinkin' p5 ports at once' is not really feasible. At the same time it is my belief that we might do better than having a full blown port with all the infrastructure (a Makefile for a completely trivial perl port, i.e. no patches and no dependencies, takes 12 lines without comments and without mandatory empty lines; pkg-plist takes 5 lines). We need to seek ways to adopt many good things CPAN.pm already does while maintaining the advantages of FreeBSD ports collection, those I described and those I omitted or missed. Having this in mind, I think that the *complete* automation as some suggested is not likely. First, pkg-comment and pkg-descr must be kept. The reasons for having them are hopefully evident. In the extreme, however, pkg-comment might be incorporated into pkg-descr if we want to reduce the amount of files per port to minimum. It is deemed useful to provide ports people with complementary tool able to _suggest_ appropriate comment and description deduced from module documentation. Then, it should be possible for 90% of perl ports to have a Makefile consisting of just one line: .include <bsd.port.perl.mk> The distfile (without version information) and its location is easily determined by the directory name. The triviality of the port suggests there is no compelling need for a MAINTAINER, which can then be automatically assigned to ports@FreeBSD.org. By default, the latest and greatest module version is used for installation, unless DISTDIR is on read-only media (but see below for distinfo considerations). If the possibility of incompatible change is perceived to be high, the LAST_KNOWN_GOOD_VERSION variable might be defined. This variable can be useful also as a hint on `supportedness' of the port. The INTERACTIVE port operations can even tell the user something along the lines The latest version of this port is 0.07. The version 0.05 was the last tested to build successfully on FreeBSD. Would you like to install the latest version (answer 1), or the last known good version (answer 2)? _ And the conservative default will be used for BATCH operations. The PLIST will be auto-generated from the information contained in module's Makefile.PL. The feasible implementation of this is possible: Makefile.PL uses ExtUtils::MakeMaker. Furthermore, ExtUtils::MakeMaker uses ExtUtils::MM_Unix. By tricking perl into loading our own MM_Unix (no patching to base system Perl is involved here) it is possible to find out exactly what files make is going to install. I could implement it this weekend. If pkg-plist is present, the current existing mechanism is used instead. The same mechanism can take care of perl-only dependencies: we get them from Makefile.PL. Same is true for patches and other files/ contents. In general, this proposed scheme will only provide more sensible defaults for perl ports to make the application of already existing ports system easier to them. It involves a bit of make(1) trickery for bsd.port.perl.mk (or should it be named bsd.perl.mk, as in bsd.ruby.mk?) and a bit of perl(1) trickery for CPAN and MakeMaker. Now the tricky part. The distinfo. Versions and security. Unfortunately, CPAN distribution does not have any MD5 checksums around. Even if it did, how do we know one can trust the CPAN ftp mirrors? :-) We might want to extend distinfo with checksums of tarballs of all known-good versions, and then again ask the user when we cannot verify the checksum for the latest version (INTERACTIVE): The latest version of this port is 0.07. The latest version I can verify the checksum for is 0.05. Would you like to install the latest version (answer 1), or version 0.05 (answer 2)? _ For BATCH operations, fall back to the latest verifiable version if NO_CHECKSUM is unset, and use the latest one if NO_CHECKSUM is set. And now the last part of this post. The beautiful naked woman is... Ahem. Sleeping yet? :-) I would like to approach here a highly controversial issue of how many levels of categories the ports collection must have. Now we have just one, and many unlucky posters were saying in the past that it is not enough. Every time the politer response was similar to `Yes, but do you realize what amount of labor the restructuring would take?'. It occurred to me that this (IMO, necessary) change can be first done on a smaller scale than the whole ports collection, and perl-related ports seem to be an almost perfect guinea-pig. First, getting rid of p5- ports from the top-level categories will substantially reduce the clutter there. textproc/ has 22% of p5- ports, and devel/ has 20%. Second, CPAN already has a rather fine-grained native categories which in most situations (the abominations like top-level FFI.pm aside) do much better classification job that current ports collection categories can provide. The nasty example here is the recent double-commit of textproc/p5-String-Strip and devel/p5-String-Strip; technically, most anything *.pm has its place in devel/ --- these are libraries, not applications, after all. Using CPAN classification the matter is clear: it is, simply and unambiguously, a String category. Third, having everything perl in perl/ or in perl5/ we can finally get rid of these ugly p5- prefixes. :-) A realize that acceptance of this last part means more substantial changes to Mk/*.mk files than anything else I suggest here. Uh well, I think it was worth a try nevertheless. Conclusion. Proposed scheme adopts the advantages present in the native Perl's CPAN.pm and keeps the existing ports collection beauties intact. It only requires incremental changes to the existing bsd.port.*.mk framework, remaining compatible with it. The perl-related ports complicated enough or those which substantially differ from the simple perl Makefile.PL && make && make test && make install model can continue to use the current ports infrastructure and in general will not be affected in any way. This last feature allows a gradual transition of older p5 ports to a new scheme. Your comments will be greatly appreciated. Thank you for your attention. Anton. -- CVS is not a substitute for communication. -- Larry Jones 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?20010105040828.A26011>