ports system woes

soralx at cydem.org soralx at cydem.org
Mon Mar 31 01:01:01 PDT 2008

> On Wed, 26 Mar 2008 14:18:00 +0100, Michel Talon wrote
> > In fact last year i wrote a python script which reads all the
> > /var/db/pkg/+CONTENTS files, and fixes all the +REQUIRED_BY files,
> > assuming they are corrupted. Moreover it follows the MOVED file.
> So you basically reimplemented pkgdb -F in python?
> > As far as i remember this program 
> > runs in a few *seconds* certainly not minutes like it is said here
> Mind that the original poster is using a very low-spec notebook with next
> to none RAM.

yes, and every developer should test their creations on something like
this :) something even slower in fact -- think PDA-like device or UMPC.
More seriously, though -- it's a midrange machine, it's fast enough
for most development tasks (think CAD, Eagle, etc), and when you think
about it, 256Mbytes of RAM is plenty. I believe the issue here is not that
this machine's RAM is too small, but /var/db/pkg is far too freakin' huge.
Over 300 entries for an X11 system? Don't make me laugh. A gazillion more
for all this GNOME/GTK stuff? Insane, I say. Look at the depndencies field
for `make search` results -- atrocious. How often do you care about a port
depending on xproto, Xlib, x..., instead of just Xorg?

Since nothing can be done about it, how about placing all the packages
that constitute base of Xorg into a separate directory in /var/db/pkg/ ?
GNOME stuff could go into another dir. Ditto for other large projects,
like KDE. The rest could stay as it is (thereby preserving the incredible
convenience and ease with which packages can be managed -- i.e., the UNiX
way of text- and filesystem-based shell tools). This would also clean up
/var/db/pkg quite a bit -- that is to say, one could more easily have a look
over which [useful|non-useful] packages are installed, without diggin' in a
directory with hundreds of subdirs.

> > solution is to use sqlite and not some half-assed solution like a
> > Berkeley database,
> Solution is to use tools that are available in our base system. SQLite is
> not.

I remember there being a thread about this some time ago, but I don't
remember -- why can't it be made part of our base? In two words...

> Pav Lucistnik <pav at oook.cz>
>               <pav at FreeBSD.org>

[SorAlx]  ridin' VS1400

More information about the freebsd-ports mailing list