Second "RFC" on pkg-data idea for ports
trevor at jpj.net
Sun Apr 18 17:23:14 PDT 2004
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:
> 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
> 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
> 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
> 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
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
-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
-bash-2.05b$ ls -1F
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
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.
More information about the freebsd-ports