From owner-freebsd-ports Fri Jul 3 16:08:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA00791 for freebsd-ports-outgoing; Fri, 3 Jul 1998 16:08:21 -0700 (PDT) (envelope-from owner-freebsd-ports@FreeBSD.ORG) Received: from mail.atipa.com (altrox.atipa.com [208.128.22.34]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id QAA00715 for ; Fri, 3 Jul 1998 16:08:00 -0700 (PDT) (envelope-from freebsd@atipa.com) Received: (qmail 3374 invoked by uid 1017); 3 Jul 1998 22:04:57 -0000 Date: Fri, 3 Jul 1998 16:04:57 -0600 (MDT) From: Atipa To: dannyman cc: "Daniel O'Connor" , freebsd-ports@FreeBSD.ORG Subject: Re: New ports scheme In-Reply-To: <19980703174558.C6665@enteract.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On Fri, Jul 03, 1998 at 01:05:54PM +0930, Daniel O'Connor wrote: > > > > > > maybe we might consider having more than one directory level? like > > > > net/irc/bitchx, net/ftp/ncftp3, etc ... ? > > > > Sounds good, except that many ports would be their entire "Application > > > Type" group. I like the idea though; add more sorting heuristics, based 3 > > > layers deep: > > > Hmm.. if they're all ogoing to be tar.gz's anyway, my not put them in a > > signle directory and use a simple DB to keep track of them. That way you can > > have one port in multiple categories.. > > It might be irritating to have a directory on one's system containing 30,000 > files, or even 1500 files ... especially if you're the FTP server distrbuting > the files in question ... we do imagine a day when FreeBSD has really taken > off and the ports collection has grown to an awesome, scarey size, and we've > planned for it to scale happily, ya? :) Well, the whole argument is scalability vs. usability. A single SQL db would be really nice for the user, but not very nice for developers and updates, unless we made some really nice tools. I do not know if people want the extra bloat of a DB application running on their machine just to manage ports. :) (ASIDE - I think RedHat is moving toward integrating a lot of their management stuff to PostgreSQL... interesting... ) > A DB would still be nice. "Multiple categories" could be kludged into the fs > with symlinks. :) Yes. I guess you'd need to establish precedence, but that wouldn't be a big problem. > Of course, with a DB interface, there's no compelling reason to keep > several hundred tarballs on your system in the first place. ;) Except that you can use fs tools (ls, etc.) to scan through them, and don't need anything more. Once again, a custom UI would be really cool and great for scalability, but we need to decide what resources must be present (X11, http, curses, etc.) to read the DB. Being able to use normal tools is a nice last resort in case those aren't available. I think all port management should be available from the command line (cat, tar, gzip, ls, etc.), but have a nice front end for convenience. I think the tarball idea gives us a bit more time, but I agree that it is not the most scalable solution. Ideas? Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message