duration of the ports freeze

Michel Talon talon at lpthe.jussieu.fr
Sat Dec 1 12:42:48 PST 2007


Aryeh M. Friedman wrote:

> My main issue is the lack of good depenancy tracking

Dependency tracking is a manual operation of the port maintainer.
There is no way to automatize it, because there is a lot more in
dependencies than shared libraries (which could be tracked
automatically). As such it is as good or bad as the port maintainer, and
there is no way to change that. You will always encounter ports with 
huge and irrelevant dependencies, instead of the ideal smallest
subset allowing the port to run.

> (leaving it to the preview of each port I think is asking for it in
> the long run) and some rather inconsistent behaviour between say the
> following three options:
> 
> cd /usr/ports/{some metaport}
> make install
> 

In my non orthodox opinion, this should be reserved to port developers
and similar power users who require maximum flexibility. For casual users
flexibility is not required at all and is more a hindrance than a bonus.

> portinstall {some metaport}

Portupgrade has never worked correctly and will never, for a lot
of objective reasons supplementing the implementation choices.

> 
> and
> 
> pkg_add {some metaport}

In my opinion, things will be better when people will finally be
convinced that binary packages are the way to go, and then use a *good*
package management system such as apt-get. A functional upgrade system
can be built for packages, but cannot for ports, for obvious reasons.
The OpenBSD people have understood that, but  now it appears that
most FreeBSD people are happy with the source based system, and all the
problems going with such a choice.

-- 

Michel TALON



More information about the freebsd-ports mailing list