From owner-freebsd-ports@FreeBSD.ORG Tue Oct 18 06:39:55 2005 Return-Path: X-Original-To: freebsd-ports@freebsd.org 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 1AF8716A41F for ; Tue, 18 Oct 2005 06:39:55 +0000 (GMT) (envelope-from wes@softweyr.com) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id B66C743D49 for ; Tue, 18 Oct 2005 06:39:54 +0000 (GMT) (envelope-from wes@softweyr.com) Received: from [204.68.178.34] (cpe-66-75-60-23.san.res.rr.com [66.75.60.23]) by smtp-relay.omnis.com (Postfix) with ESMTP id 5823020068B0; Mon, 17 Oct 2005 23:39:52 -0700 (PDT) In-Reply-To: <20051018011616.GA57969@xor.obsecurity.org> References: <20051015053003.GB28137@soaustin.net> <4350CE50.8080704@ebs.gr> <5739E97B-7EDC-4971-9EA5-01A44688A981@softweyr.com> <43522953.6050700@ebs.gr> <1B8112AF-8C0E-4BA0-8D1C-DA6AD529F327@softweyr.com> <20051017153024.GA23494@arabica.esil.univ-mrs.fr> <20051017212748.GD71766@isis.sigpipe.cz> <790a9fff0510171505i4010cc05yc30f67d459d1a0e4@mail.gmail.com> <20051018010446.GH71766@isis.sigpipe.cz> <20051018011616.GA57969@xor.obsecurity.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Wes Peters Date: Mon, 17 Oct 2005 23:39:52 -0700 To: Kris Kennaway X-Mailer: Apple Mail (2.734) Cc: Scot Hetzel , freebsd-ports@freebsd.org Subject: Re: [SUGGEST] Reform eclipse and eclipse related ports X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2005 06:39:55 -0000 On Oct 17, 2005, at 6:16 PM, Kris Kennaway wrote: > On Tue, Oct 18, 2005 at 03:04:46AM +0200, Roman Neuhauser wrote: > >> # swhetzel@gmail.com / 2005-10-17 17:05:18 -0500: >> >>> On 10/17/05, Roman Neuhauser wrote: >>> >>>> Wes said: "I have to resort to 'make search'" which >>>> presumably means >>>> he'd prefer to just ls /usr/ports/$emacs_category; while 'make >>>> search' is a bearable interface (FMPOV), you can't beat a ls. >>>> >>>> Hey, what about materialized virtual categories? A bunch of >>>> symlinks, and everyone's happy. Or is that too much for CVS? >>>> >>> >>> It would probably be too much for CVS to handle, instead someone >>> could >>> modify bsd.port.mk to create the virtual category directories and >>> then >>> symbolicly link the ports into these categories. >>> >>> The following could be added to bsd.port.mk >>> >>> virtualport: >>> .for CATEGORY in ${CATEGORIES} >>> .if not exist ${PORTSDIR}/${CATEGORY} >>> mkdir ${PORTSDIR}/${CATEGORY} >>> .endif >>> .if not exist ${PORTSDIR}/${CATEGORY}/${PORTNAME} >>> ln -s ${.CURDIR} ${PORTSDIR}/${CATEGORY}/${PORTNAME} >>> .endif >>> .endfor >>> >>> which would add the link for a specific port. The we would need to >>> add a virtualports target (bsd.subdir.mk?) that would decend thru >>> all >>> the ports creating all the symbolic links (similar to the "make >>> readmes" target used in /usr/ports/ ). >>> >>> Also there would need to be another target that would remove all the >>> symbolic links, that way you could re-create them without worrying >>> about removed symbolic links pointing to non-existant ports. >>> >>> NOTE: Non of this code has been tested. If you want this feature, >>> work >>> on improving the code and submitting it as a patch to the PR >>> database >>> for Ports Managers to accept/reject. >>> >> >> I'm putting this in my .plan, and will eventually work on it >> unless >> someone points me at a past discussion that showed there were >> major >> technical obstacles to this. >> >> I think I could manage inside /usr/ports/Mk: >> >> * create an update-vcats that works in all of portsdir, >> portsdir/category and portsdir/category/port >> * maintain a list of names of virtual categories in a make >> variable >> * create symlinks in the virtual categories this port lists in >> CATEGORIES >> * delete symlinks to this port from other virtual categories >> if any >> >> But I'm quite concerned about the changes needed to make >> things like >> the package building cluster or make index aware of this. It >> looks >> like it would have quite far reaching consequences. Kris? >> > > I don't have time to think about this much, but it seems to me that > keeping all the symlinks up to date requires a time-consuming walk of > the entire ports tree. However, I'm not sure package builds or index > builds need to know anything about this, since they can just ignore > the symlinks (which represent a duplicate path to the same directory) > and proceed as now with how they do things. Thanks for eliding the mud-slinging and getting back on track here guys. I think a better, more easily searched index to the ports system is an admirable goal. How it is implemented is a task I wouldn't presume to dictate to people who know the ports system so much better than I do. The ability to easily tab-search through sensible ports categories does make it much easier to find ports, especially when you have some idea of what the port name might be. Tools like 'make search' work well when you don't know what you're looking for all that well, but are a pretty broad axe to apply to, for instance, finding the eclipse gui editor (I know it's eclipse-g{something} or eclipse-v{something}) or a specific kdemultimedia codec. I'm not pointing this out for my use; I'm pretty adept at finding stuff in ports. I have a lot of co-workers who are experienced programmers but not necessarily experience FreeBSD'ers and they often have trouble finding ports even when they (almost) know the name. -- Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com