[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
LIB_DEPENDS vs. package updates
- To: tech_(_at_)_openbsd_(_dot_)_org
- Subject: LIB_DEPENDS vs. package updates
- From: Marc Espie <espie_(_at_)_nerim_(_dot_)_net>
- Date: Wed, 3 Nov 2004 07:47:15 +0100
- Mail-followup-to: tech_(_at_)_openbsd_(_dot_)_org
- Reply-to: espie_(_at_)_nerim_(_dot_)_net
This is an issue that I knew would bite, but which I just saw.
LIB_DEPENDS implicitly recurses through RUN_DEPENDS and LIB_DEPENDS.
So, when trying to update a package directly, the forward dependency
check will find direct library dependencies, but not indirect ones.
Thus, updating gettext will lead from libintl.so.1.1 to libintl.so.2.0,
and direct dependencies will be happy, such as gtk+.
Indirect dependencies won't.
There are several ways to solve this.
- with binary packages, a bit wasteful: always consider the transitive
closure of forward dependencies for shared libraries, e.g., lock all
packages that depend upon something that depend on libintl.so.1.1
to libintl.so.1.1, and refuse for it to vanish.
- with ports, hard to do: stop recursing in LIB_DEPENDS_CHECK, so that
people have to mention all library depends.
- the one I'm favoring. Introduce a LIB_DEPENDS_EXTRA variable, which will
hold only the library specs, and no packages specs at all. This variable
should hold all libraries that the package will depend upon. Both
lib-depends-check and package create will use this variable to discover
and flatten LIB_DEPENDS_CHECKs...
There is still the issue that, potentially, a given library may come from
another package that just happens to match the same dependency path, but
I don't think we need to worry about that right now.