[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: NetBSD vs FreeBSD
On Thu, 4 Aug 2011, Alex Goncharov wrote:
> | 1. it allows pkgsrc packages to be built with exactly the versions of
> | software that are wanted, and not what happens to be already installed
> | in /usr/local - to illustrate, imagine that ncurses is installed, and
> | another package's configure script checks for the presence of ncurses
> | (bad example, since i think freebsd has ncurses in base, but ykwim)
> This all seems very far-fetched.
It is certainly a real issue. Many software when built outside of ports
(or outside of pkgsrc) defaults to installing to /usr/local/. So simply
the addition of an include file, some binary, some library, some
pkg-config file, et cetera, may in the future
enable/disable/break/enhance or otherwise change some later "ports"
build resulting in a package possible different than what was expected.
Even if the package list is the same, it may have new dependencies or
capabilities not expected. And after removing the "/usr/local" addition
(whatever it was) may break the package like removing a shared library
(and since not registered as a package dependency it won't warn you).
Even if you choose a custom localbase, the problem is still possible
since /usr/local is often still looked at. pkgsrc builds work very
hard to make sure /usr/local and /usr/pkg are not looked at when
> ls -d1 /usr/ports/databases/postgresql*server
> ls -d1 /usr/ports/databases/mysql*server
> s -d1 /usr/ports/editors/openoffice.org-*
> Does one really need more than that?
I think there was a misunderstanding, so I don't understand context of
> | 2. isolates dependencies so that dangling or hidden dependencies just
> | do not happen.
> 'pkgdb -F' won't do it for you on FreeBSD?
Also different. That is for fixing later.
The "hidden" dependencies in question are those detected at build time
> | in addition, from a user's pov, pkgsrc's config file handling is done
> | in a smart way so that any changes to standard configs are preserved,
> | rc.d scripts can optionally be installed to /etc so that they work
> | out
> Any port rc.d script is installed (with either install method) under
> /usr/local/etc/rc.d and works out of the box (subject to rc.conf
> X_enable=YES, of course).
Yes. pkgsrc offers "staged" rc.d scripts, so they are installed as
examples and optionally put in place to use (if a custom version is not
> | of the box, and much, much more.
> It is quite possible that pkgsrc has some advantages for a very
> sophisticated use, but it seems to me that in comparing it with
> FreeBSD ports some of the obvious capacities of the latter are
> Such as '-p' and '-P' of pkg_add:
pkgsrc had those too. I think the master/slave mode was removed, but
basic functionality of these are the same. Note that the FreeBSD-style
of "staged" (master/slave) mode at binary package install time is
different than pkgsrc's build-time staged installs. (I am curious does
anyone use FreeBSD's pkg_add master/slave installs and why?)
The concept of changing the install prefix at pkg_add time is much
different than choosing a custom prefix at build time.
Main Index |
Thread Index |