On Mon, Dec 29, 2003 at 08:12:14AM +0100, Sebastian Prause wrote:
> hi,
> i have one problem with the current buildlink situation: every time i upgrade
> pkgsrc and want to install a new package, or update one, i find myself having
> pkgsrc fail because it tries to pull in _all_ dependencies, even if i have them
> already installed. the problem here is that buildlink knows nothing about
> version numbers. i mean it's a good idea to keep the installed software 
> up-to-date, but its a pain to just update a library for a package that doesn't 
> require the latest version of the lib. this makes pkgsrc a lot harder to use
> (and thus less useable).
> 
> a good example would be libvorbis. consider i want to upgrade mplayer, then
> pkgsrc would fail with libvorbis because it's already installed. now updating
> that would be a pain, because its used by those packages on my system: 
> 
>   vorbis-tools-1.0.0.8nb6, arts-1.1.4, kdelibs-3.1.4, kdebase-3.1.4, 
>   mosfet-liquid-0.9.6.0.4, kdenetwork-3.1.4, kbiff-3.6.3nb3, kdeutils-3.1.4
>   kdeadmin-3.1.4, kdeartwork-3.1.4, kdeedu-3.1.4, kdegames-3.1.4
>   kdegraphics-3.1.4, xine-lib-1rc0anb1, kdemultimedia-3.1.4, kdeaddons-3.1.4
>   kde-3.1.4, kde-i18n-de-3.1.4, koffice-1.2.1nb4, ogmtools-1.2, mencoder-1.0rc2
>   xmms-1.2.7nb10
> 
> 
> my question is, can this be changes _easily_? what about the DEPENDS stuff?
> is it still used? is it very different from builldink (both is used to pull in 
> dependencies, right?)? would it be possible to use only that and let pkgsrc decide 
> to use either buildlink or the old behaviour?
> 
> what do others think about it?

Arguably, we could record more precise version dependencies in a package Makefile.
But there are several issues, and on that front libvorbis is indeed a good example.

The problem is that the buildlink2.mk file of, in the example, libvorbis, comes
from the pkgsrc tree, and not the installed package.  Thus, it reflects the pkgsrc
package, not the installed one.

This is usually harmless for a simple PKGREVISION bump, and most of minor number
bumps, though there can be some issues if, say, headers get reorganized and
buildlink doesn't link the good ones.

When there is a major number bump for a library, such as in latest libvorbis
update, the buildlink2.mk file is almost guaranteed to not match the installed
package.  That's why we have to bump revision for every dependencies: you can't
mix packages built against previous library version with packages built against
new version (well, in the buildlink2 world, IIUC this will hopefully not be true
in the buildlink3 framework).

Now, solutions...  I guess one would be to start buildlink3 switch.  Another
would be to embed the buildlink2.mk (in some way) into the package, and use
that file instead of the one in pkgsrc.  There are two issues with that: really
increased complexity of the framework, and we would still have to record
minimum versions in each dependency's Makefile.

Can someone confirm my thoughts about buildlink3?

Quentin Garnier.