OpenBSD Journal

Porting Notes: New Shared Library Numbering Controls

Contributed by todd on from the help-wanted dept.

As noted this morning by Marc Espie on ports@, OpenBSD's ports infrastructure was just modified to permit control of all shared libraries in ports, which is consistent with the way the main source tree treats shared libraries.

If you are a porter, now is the time to consider talking to 'porters' about adding manpower to effort to go through the entire ports tree making these changes.

Marc's original post, below, is very clear on why this is happening:

Various reasons (C++ mangling, mostly) have compelled us to finally implement some stuff we've wanted for some time: fine control over shared library versions.

Simply put, there are basic reasons (like C++ compiler changes) which mean that the ports tree should have control over shared library numbers.

We've also known for a long time that people in the free software world do not play it safe in general: they do not bump shared library numbers each time they should (this often comes from a misguided idea among linux people that binary compatibility is a must, so they try really hard to make things work without ever breaking binary compatibility, but sometimes they break it anyways, and they do not bump versions and they lose).

We have taken the opposite approach: we prefer to bump libraries each time we think things are not safe. The end user will see lots of shared library versions accumulate on his system. So what ? since all dependencies are now registered, he (or she) can now remove .libs-* packages that reference stuff that isn't used anywhere.

So, I just committed the basic framework that allows this to happen, and you will see in the following days most ports being converted to give us control over those libraries. There will be a few bugs, that will get solved.

Once enough examples are committed, we expect the average porter will understand what's involved.

This basic framework may need further tweaks to cope with common issues. We'll see...

Since this is a fairly open project, I apologize for not involving the general community in that discussion (too much to do, too little time), but at least, now, you know. ;-)

(Comments are closed)


Comments
  1. By Anonymous Coward (201.29.137.242) on

    Now that OpenBSD have a mature ports system, is there any chance to port those efforts and create pkg_* tools that can make binary upgrades/updates system-wide ? All I wish is to have an apt-like system, with worldwide patch repositories with binary upgrade/update packages.

    Comments
    1. By Anonymous Coward (201.29.137.242) on

      Complementing: Yes, I know it is easily doable (just check Gerardo's work). But the thing is: Is it easily approved by theo@ and marc@ ? It may demand bandwidth and hardware.

      The "no" is guaranteed, let's fight for the "yes".

    2. By Dominik (213.212.203.90) on

      check out http://openbechede.sourceforge.net/en/
      is not apt, and is not perfect, but better than nothin' :)

      Comments
      1. By Brad (216.138.195.228) brad at comstyle dot com on

        sorry but apt should NOT be a guideline for doing things, and that is setting the bar pretty low for expectations of the OpenBSD package tools.

      2. By Anonymous Coward (201.29.137.242) on

        openbechede is released under the GNU/GPL license.

        Nice idea.

    3. By Anonymous Coward (216.220.225.229) on

      The foundation for this is being slowly built into the pkg tools.

    4. By phessler (69.12.168.114) on

      all I wish is for the apt brain-damage to stay far, far, far away from openbsd. I'm not a fan of running `apt-get update` and having it delete all of my kernels.

      Comments
      1. By Anonymous Coward (198.53.128.225) on

        Not much experience with apt-get, right?

        Comments
        1. By phessler (209.204.157.106) on

          on the contrary, that example is directly *from* my experiance with apt-get. its a worthless tool, written by worthless tools.

          Comments
          1. By Anonymous Coward (217.185.36.242) on

            Sounds like you should learn how apt-get works *before* you slam it. Apt's pinning feature would solve your problem by negating the packages you don't want touched/upgraded (just as yum is capable of doing as well). If you don't want your kernel packages touched, tell apt-get via /etc/apt/preferences using 'pinning'. It's well documented at debian.org and in apt's man pages . Reading the documentation to verify that something works the way you believe it should is usually the best answer, rather than spreading 'misinformation'.

    5. By Frank Denis (82.224.188.215) on http://www.manucure-pro.com

      Binary upgrades are ok (pkg_add -ui).

      What I really miss in OpenBSD is source upgrade, ie. something that recompiles and updates installed ports (a la "emerge -u --deep world" in Gentoo).

      Comments
      1. By Anonymous Coward (213.118.74.206) on

        Binary upgrades are ok (pkg_add -ui).

        Wow this is great!... I didn't know about this cool feature until now... Guess I should keep up better with the rapid development :)

        (time to go and re-read some manpages!)

  2. By Marc Espie (213.41.185.88) espie@openbsd.org on

    Sigh... how comes there's never anything new in these discussions ?

    Updating the base system will happen in due time. It's not as trivial as this project makes it look...

    As far as shared library stuff goes, time for some progress report:
    over 1/3 of the ports tree has been converted and is now happily using SHARED_LIBS... it's somewhat boring work, but so far, things go on at a reasonable pace.

    (note that there are almost 500 ports with shared libraries... 1/3 means over 150 ports, which is not really small, all things considered)

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]