duration of the ports freeze

[Aryeh M. Friedman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michel Talon wrote:
> 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.

This is due to thinking of the port system as one would of as say
make(1) namely a multistage transaction vs. one big atomic
transaction.   Doing first makes each port responible for most it's
knowledge and thus open to inconsistencies and the other makes so the
port is nothing but a node in a graph with the edges holding most of
the knowledge instead of the nodes.
>
>> (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.

Is this any reason to make so metaports are the only way for anyone to
do anything.  Flexibilty != more to manage if done right.
>
>> portinstall {some metaport}
>
> Portupgrade has never worked correctly and will never, for a lot of
> objective reasons supplementing the implementation choices.

If there was a universal way of handling stuff as recommended in
Miller97 and most decent algorithm books.
>
>> 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.

This is like NASA saying since we got to the Moon on WWII tech and 4
function calculators that we should continue to use it.... the ports
system is basically based on mid 70's software engineering methods (at
best more likely late 60's)... is it wrong to ignore the potential
benefit of 30 years of collective experience in building large
interconnected systems?


- --
Aryeh M. Friedman
FloSoft Systems
Developer, not business, friendly
http://www.flosoft-systems.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHUc22358R5LPuPvsRArA8AJ4v+1HFCYe2xhMOz4ByxvwtI6XmagCcC+Xi
mWhz0CEGWv2XutnF56zTl64=
=u1IE
-----END PGP SIGNATURE-----