From owner-freebsd-ports@FreeBSD.ORG Tue Apr 13 10:47:08 2004 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 795E716A4CE; Tue, 13 Apr 2004 10:47:08 -0700 (PDT) Received: from smtp0.server.rpi.edu (smtp0.server.rpi.edu [128.113.53.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23AFC43D48; Tue, 13 Apr 2004 10:47:08 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp0.server.rpi.edu (8.12.8/8.12.8) with ESMTP id i3DHl7Ed027447; Tue, 13 Apr 2004 13:47:07 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200404131516.i3DFGMJA078941@green.homeunix.org> References: <200404131516.i3DFGMJA078941@green.homeunix.org> Date: Tue, 13 Apr 2004 13:47:05 -0400 To: "Brian F. Feldman" From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) cc: freebsd-ports@freebsd.org Subject: Re: Second "RFC" on pkg-data idea for ports X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2004 17:47:08 -0000 At 11:16 AM -0400 4/13/04, Brian F. Feldman wrote: > >... will cost us ease of use in creating and updating ports, >certainly, because the developer cannot simply type >`diff file{.orig,file} > patchfile' and be finished with it. There would be an extra step (or two) here, yes. >Searching through UNINSTALLED ports, I often want to find out >what port would have a certain file in its PLIST, If the port is not-installed, then it does not have to be in the pkg-data format. One idea of the pd-handling-program is that it knows how to handle ports in either their present format or the new pkg-data format. >and I also would not be able to just >`grep ^whatever ports/foo/*/pkg-plist' in the common, >single-plist case. Of course, the tool wouldn't make it >that much harder to do something similar, but it would >be twice the typing. We could maybe hide that typing behind a make target, similar to `make search index=xxx' and `make search key=yyy' >I'm not sure I understand why you don't just go all the way >and embed it in the Makefile. That was actually my original idea, but after working with it a bit I felt it was just too unwieldy. I'm also going to claim (without proof...) that we might eventually be able to move so much into the pkg-data file that most ports could use the exact-same Makefile. But that would be way off in the future, if ever... >Is it because make(1) is "slow"? Since pkg/COMMENT turned >into pkg-comment and then COMMENT= in the Makefile, it's not >hard to imagine the same could be done for >pkg/DESCR -> pkg-descr -> DESCR=, ... I was here for the pkg-comment -> COMMENT change. It was not trivial. It was committed, it broke things, and it had to be backed out. In fact, that was exactly what inspired this idea. After more effort was put into it, it was committed again. And that was for a single-line value, which had no embedded newlines and which was less-likely to have "special escaping characters" in it than something like pkg-descr is. I think that stuffing all these values into MAKE variables is much more trouble than it is worth. That is just MO, of course. >Heck, even if Makefile became, itself, the XML PkgData file >that defines everything in every port, it's not like there >couldn't be a portmake(1) that did "PkgData --Makefile" and >called make(1) with all the rest of its arguments except >doing a file descriptor redirection or temporary file >redirection and adding a -f . Hrm. That is an interesting idea which I had not thought of. Maybe do that as a future project. For now I assumed that people would expect me to keep the ability to: cd /usr/ports/category/portname make && make install && make clean Ie, that those *exact* commands would continue to work, with the exact same result. And I think implies a standard makefile in that directory. And a makefile which does not depend on installing some new version of the `make' command. Those were just the assumptions I started with, though. >Is there some reason you would stop where you did other than >just to keep the Makefile separate? Mainly to pick a project which Darren and I might actually complete. This is mainly moving forward because a recent RPI graduate (Darren Lim) has a few months where he has some spare time. If we can *complete* this project in that time, all the better for everyone. If it takes longer than that, then Darren is gone and I am my usual lame always-out-of-time self. The project will never get done. Also, while Darren now has a Phd, he has done practically zero work with sysadmin or systems-programming. So, we are not open for "wish-lists" of things that people would rather we work on. There are many very good projects waiting to be done, but that doesn't mean Darren is the right guy to tackle them. >This is a very slippery slope. I don't think ports should be >an XML package definition -- that's just not the BSD way. Well, I am guessing this might be taken as a "NO" vote... :-) -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu