Optional dependency tracking

[davidchisnall]

The ownCloud port recently changed the default back end from sqlite to mysql. This meant that the PHP MySQL parts were unconditionally installed and pkg autoremove attempted to uninstall the PHP SQLite parts (which would break existing installs). The choice of back end to use is currently made at port build time, which used to be fine when ports were built by end users but is problematic now that ports are built into packages. In this particular instance, all of the back ends are supported, as long as the required dependencies are installed.

The correct solution would be for the package to specify that (at least) one out of the PHP sqlite, mysql, or postgresql PDO packages should be installed for it to work. pkg add would then prompt the user to install one of them and track it as a dependency.

[vstakhov]

That's a task for provides/requires and the new dependencies strategy we've discussed during BSDCan. But I'm too busy these days to summarize and post the details to the public mailing list.

[bapt]

You mean with a "or" ? like require sqlite3 or mysql or postgresql?
I haven't thought about but this seems interesting, maybe we could have some "weight" on an optional dep so if nothing is already there one would be the default automagically

[vstakhov]

Depends: pkg1 | pkg2 | pkg3

So pkg would try pkg1 then pkg2 then pkg3.

[bapt]

ah so even simpler! Great we can start using that once pkg 1.6 is out !

[cstdenis]

That sounds like it could also work around issues with multiple versions of packages such as php.

If I install a web application package that was built/packaged with php 5.y, but have php 5.z installed, pkg tries to install a second copy of php. This will obviously fail, and is completely unnecessary since most packages just specify USE_PHP with no version.

I suspect the same is true to perl, and possibly python. May also work with packages like postgresql, but that is more complex because it involves linking against C libraries, tho it sounds like it's forward comparable* (binaries compiled against 9.1 should run with installed version 9.2, etc)

• http://postgresql.nabble.com/Details-about-libpq-cross-version-compatibility-td5723830.html