Re: NetBSD vs FreeBSD

[Alex Goncharov <alex-goncharov%comcast.net@localhost>]

,--- You/Jeremy (Thu, 4 Aug 2011 09:19:43 -0500 (CDT)) ----*
| 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).

I seem to beginning to understand it: the problem may happen if you
combine building from ports/pkgsrc -- and "by hand". Right?

Makes sense, even though this has never been an issue for me
personally -- I always specify '--prefix' to something different than
'/usr/local' (and for a long time I don't even build anything outside
of ports on FreeBSD -- only on other platforms).

| 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 
| building packages.

I see.  How does this work when one needs the information about
installed packages? E.g. for x11-related things (gconf), or for ODBC
drivers, which need some information from things like 'pg_config' or
'odbc_config'?


| > ----------------------------------------
| > ls -d1 /usr/ports/databases/postgresql*server
| > ls -d1 /usr/ports/databases/mysql*server
| > ----------------------------------------
| > 
| > Does one really need more than that?

| I think there was a misunderstanding, so I don't understand context of 
| that.

I was trying to illustrate the wide choice of available versions in
ports.  Not so significant, we can move on.

| > | 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 
| (described above).

I see.

| > | 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 
| already there).

As in ports.

| > | 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
| > overlooked.
| > 
| > 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?)

Have no clue, don't even know what it is.
| 
| The concept of changing the install prefix at pkg_add time is much 
| different than choosing a custom prefix at build time.

OK.

Thank you for the detailed analysis!

-- Alex -- alex-goncharov%comcast.net@localhost --