Date: Sun, 18 Apr 2004 20:24:03 -0400 (EDT) From: Trevor Johnson <trevor@jpj.net> To: Mark Linimon <linimon@lonesome.com> Cc: freebsd-ports@freebsd.org Subject: Re: Second "RFC" on pkg-data idea for ports Message-ID: <20040418191720.V40588@blues.jpj.net> In-Reply-To: <Pine.LNX.4.44.0404171330130.26375-100000@pancho> References: <Pine.LNX.4.44.0404171330130.26375-100000@pancho>
next in thread | previous in thread | raw e-mail | index | archive | help
Mark Linimon wrote: > 1. (easy) If the distinfo lines were moved into the Makefiles, that > would result in a savings of 9568 files out of 10149 ports (60075 files), > for about 16%. (Note: I'm using the numbers from an old tree, but the > percentage has probably not changed significantly). > > (Disclaimer: although I personally am not really fond of this solution due > to the repo-churn it would create, I know that other people are pushing > for this to be done). I have a patch with which, if desired, this could be done incrementally when each distinfo would be updated anyway, avoiding most of the churn: <URL:http://www.freebsd.org/cgi/query-pr.cgi?pr=62761>. > 3. (advanced) Right now our default assumption is that to install any > ports, you have to install the entire ports collection. This is true > whether you install ports via downloading and unzipping the tarball > from our main site, or use cvsup. Perhaps it's time to reevaluate this > assumption. [...] > 3b. (somewhat easier) Figure out ways to not have to have the entire > hierarchy loaded. [...] > (As an example, my other conclusion from that shell-script run was > "everything depends on devel, and devel depends on everything else". > Since devel has 1184 ports in it, it's difficult to attack the overall > problem without attacking devel ...) I don't know much about Pear at all, but would a ports/Mk/bsd.pear.mk to replace ports/devel/pear-PEAR/Makefile.common be worthwhile? IIRC many Pear ports in other categories can't even be fetched without having the Makefile.common. > I honestly don't think anyone in the FreeBSD project really has a handle > on what that dependency graph looks like. And this is where I think your > desire to have someone work on the inodes problem, who doesn't have an > intricate knowledge of coding to the existing infrastructure, could be > invaluble. > > There are various ports in the tree (graphics/graphviz; graphics/ > meshviewer; graphics/vcg) that might be really useful to shed some > light on the data structures. To my knowledge, no one has ever done > this for the FreeBSD ports, if, indeed, for any of the various > open-source OSes at all. [...] It's been done for Debian: see <URL:http://www.debianplanet.org/node.php?id=695>; and <URL:https://init.linpro.no/pipermail/skolelinux.no/cinelerra/2003-November/000671.html>; for instance. When the files were moved out of the pkg/ directories, there was discussion about moving files out of the files/ directories too. As I recall, Satoshi Asami disapproved of the idea because the "ls" output would look messy. At the time, patches were uniformly named in the patch-aa, patch-ab, ... style that doesn't include the name of the patched file, so if this were done now the messiness would be greater than it would have been back then. There are around 5500 files/ directories though, and many of them contain just a few patches. The messiness IMO would be tolerable--here's what the accessibility/at-spi port looks like now: -bash-2.05b$ ls -F CVS/ distinfo pkg-descr Makefile files/ pkg-plist and how it would look after this change: -bash-2.05b$ ls -F CVS/ patch-registryd_Makefile.in Makefile pkg-descr distinfo pkg-plist patch-libspi_Makefile.in -bash-2.05b$ ls -1F CVS/ Makefile distinfo patch-libspi_Makefile.in patch-registryd_Makefile.in pkg-descr pkg-plist The patch files all have patch- prefixed to their names, so they are grouped together when sorting by name rather than by size or date. To get a listing of just the patches, one could do "ls pa<TAB>*" which is only two more keystrokes than "ls f<TAB>". If someone wanted to see just the Makefile, distinfo, pkg-descr and pkg-plist files, making an alias for "ls|grep -v ^patch-" does not seem horribly painful. For ports that have numerous patches, the port's Makefile could set PATCHDIR= ${MASTERDIR}/files so that the present layout is preserved (the change I am talking about implies making PATCHDIR default to MASTERDIR). For each files/ directory, cvs users also get files/CVS/ and its contained Entries, Repository and Root files--five inodes in all. -- Trevor Johnson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040418191720.V40588>