From owner-freebsd-ports@FreeBSD.ORG Tue Apr 13 12:43:04 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 8DA8816A504 for ; Tue, 13 Apr 2004 12:43:04 -0700 (PDT) Received: from smtp0.server.rpi.edu (smtp0.server.rpi.edu [128.113.53.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4709443D31 for ; Tue, 13 Apr 2004 12:43:04 -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 i3DJgvEd027904; Tue, 13 Apr 2004 15:42:58 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <407C37E7.3080906@ciam.ru> References: <200404131516.i3DFGMJA078941@green.homeunix.org> <407C37E7.3080906@ciam.ru> Date: Tue, 13 Apr 2004 15:42:56 -0400 To: Sergey Matveychuk 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 19:43:04 -0000 At 10:56 PM +0400 4/13/04, Sergey Matveychuk wrote: >Garance A Drosihn wrote: >>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. > >It may be quite appreciably for me as a ports developer. When >I create or update a port I need to diff, test and to diff >again and agian. And we'll get more complex port >creation/updating process. So we'll make developers' life harder. I certainly do not wish to make it much harder. Please note that any "pkg-data project" can exist in two states. The normal, archived state (where all the information is in the single file), and the expanded state. When in the expanded state, some of the information is in a "pkg-data-wip" file ("wip" for "work-in-progress"), and some of it is in plain files, in a plain directory, just as it is in the current setup. Thus, as stated on the web page, I suspect that a developer would: (a) expand the pkg-data file, (b) do whatever work they need to do, (c) test test test, (perhaps going back to #b several times) (d) --contract all those work files back into the original pkg-data file, (e) and finally `cvs commit' the result. You would not need to contract/archive the information back into a pkg-data file to test any of your changes. That is my intent, at least, although I am sure the details will be important to people, and we may need to take a few shots at getting those details right. So, my THEORY is that there are just two extra steps for working on any port. Step (a) and step (d). All the other steps would be done the same way you do them now. I do understand that even "just two extra steps" will add up when applied to the entire ports collection. Perhaps that is not worth it. That is why I am asking for feedback now, instead of after doing all of the work. >>We could maybe hide that typing behind a make target, similar >>to `make search index=xxx' and `make search key=yyy' > >Of course we could. >But we can't to change all mighty-unix-tools with any target >anyway. I am sorry, but I do not understand this sentence. I am not sure what you mean by it. >Do you think saving inodes outweigh all unconveniences we'll get? Uh, yes. Obviously I would, or I wouldn't offer to spend a lot of time and effort to make it happen. I might be wrong about how useful this change is, but I (personally) at least *THINK* that it is worth doing. Also, there is more going on here than just saving inodes. I only described that because it is something that can be easily measured. [And also, my hope is that the result will not be as inconvenient as you fear it will be. Again, I could be *wrong*, but my *goal* is to not make anything harder for developers.] >>Well, I am guessing this might be taken as a "NO" vote... :-) > >Sorry, my vote is "no" too. Okay. Thanks for the feedback. If I get enough "no"s, then I will happily move on to other projects. No hard feelings on my part. I wouldn't want to do this if developers object to it. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu