Re: NetBSD vs FreeBSD

[Aleksej Saushev <asau%inbox.ru@localhost>]

Alex Goncharov <alex-goncharov%comcast.net@localhost> writes:

> ,--- You/Aleksej (Wed, 03 Aug 2011 11:47:27 +0400) ----*
> |
> | Another thing I didn't like in FreeBSD after getting acquainted with NetBSD,
> | is its ports. Having performed few critical upgrades of FreeBSD 
> installations
> | I know pretty well where pkgsrc would have helped us not doing extra manual
> | work under hard time constraints.
>
> My impression from using NetBSD was that it's basically the same as ports:
>
>    make -C X/a/b install [package] -> Y/(bin,lib,...)
>
> only an X and Y being different for the two OSes:
>
>   NetBSD: X=/usr/pkgsrc, Y=/usr/pkg
>   FreeBSD: X=/usr/ports, Y=/usr/local

If you don't go any further than just installing few packages and
updating leaf ones, then you may have this impression. Real life is more
complex than that.

> I.e. if you use a "source" install, not installing pre-built packages.
>
> Do you remember any specifics about the ports pains you had, absent from 
> pkgsrc?

Sure.

The first and the main problem is that FreeBSD packages don't depend on
packages, they depend on files instead. This means that if you have some
stray file in your /usr/local, you get wrong assumptions when building.

Consequences go far beyond a mere inconvenience: you have to manipulate
your installed packages to get consistently built dependents, you have
to watch out for correct handling of packaging list, the latter is
non-trivial given the complete absence of staged installation support,
there's no way to restrict versions of compatible packages, which means
that you have to watch for it yourself, and so on. In conjunction with
no isolation of build environment from installed packages this can cause
an update nightmare.


Another problem is that it is impossible (or rather hard at the very least)
to deploy parallel installation of packages under another prefix.

This means that once you need to use a conflicting package, you have
to employ various overly complex tricks for it. With pkgsrc I bootstrap
another set of tools and after that I have easy access to another
version of PostgreSQL client and server, another set of MPI tools,
another set of TCL tools, packages from another pkgsrc branch, and so on.
This also allows rather convenient maintainance approach, when you never
update your packages (you build and install new ones instead, just use
another prefix like "/usr/pkg-2011Q2").


-- 
HE CE3OH...