That’s a pretty cryptic headline, isn’t it? John Marino has ‘privatized’ several libraries in DragonFly, so that they can’t get included involuntarily as part of a port build. That may mean you will need to perform a full rebuild of your system if you are tracking DragonFly-current.
(This is the way to fix ‘system’ languages like Perl was in FreeBSD 4.x – keep them clearly separate from the port version. It’s about a decade too late for that idea to work out, though.)
For example, lets take CentOS 6, which uses python 2.6 as system language (suppose v2.6.2). So when I’ll install python-2.6.6.rpm I’ll update a system library and this may break the system. With “privatization” I can have v2.6.2 and v2.6.6 at the same time. Am I right? I just can’t understand what “privatization” is.
I may have confused the issue a bit by mentioning perl – this isn’t a system language issue, rather system libraries. DragonFly comes with libcurses (for example; there are other libraries) installed for a variety of things , but there’s a different and sometimes newer version of curses in ports.
There are programs in ports that need curses, and so have dependencies on libcurses when being built. Those ports have curses as a dependency, and so will bring it in automatically when building. However, it’s possible that the version of libcurses already in the system will get linked instead of the ports version, so the ports software getting built could end up with the wrong library versions installed.
This walls off the system versions of various libraries, so that what gets built and linked with ports is the known, correct versions from ports. The same goes for system stuff – it will never get accidentally linked with a ports version of something and then break when that port is upgraded.
Thanks for explanation, Justin! Everything became clearer.