libvirt @ 0.8.7 - new port submission

[jclift@…]

Initial Portfile submission for libvirt 0.8.7.

Libvirt is a virtualisation management API and associated utils.

Originally developed on Linux, but has recently expanded to work on OSX and other OS's.

[jclift@…]

In order to generate its HTML documentation, this port file depends upon the new xhtml1 port submitted as #28166

[ryandesign (Ryan Carsten Schmidt)]

Is xhtml1 a library dependency as indicated in the portfile (i.e. does libvirt use xhtml1's files at runtime as well), or is it only a build dependency as mentioned above?

[jclift@…]

Just at build time. It uses the xhtml1 files in the generation of the documentation, and that's it.

What needs to be changed? :)

[ryandesign (Ryan Carsten Schmidt)]

We'll just change depends_lib to depends_build for the xhtml1 dependency.

The next problem is that the build fails for me with the following message:

libvirtd.c:1298:4: error: #error "UNIX socket credentials not supported/implemented on this platform yet..."

I'll attach the complete log.

[jclift@…]

Interesting. That error is caused by it finding the port for PolicyKit.

Hadn't tested against that, as I didn't know PolicyKit worked on OSX. :)

The workaround is pretty simple. Just need to add "--with-polkit=no" on the ./configure line.

Are you ok to try it?

[ryandesign (Ryan Carsten Schmidt)]

Ok, it builds now. It looks like it links with libraries from a lot of ports it's not declaring dependencies on, though:

• avahi
• curl
• cyrus-sasl2
• dbus
• libidn
• libssh2
• libxml2
• openssl
• zlib

Some of these probably interrelate (for example, libidn, openssl and zlib are there because of curl) so not all of these need to be listed as dependencies, but some of them probably need to be, or if these are optional features we don't want, they should be turned off with configure flags.

[jclift@…]

Thanks Ryan, that's definitely interesting.

Some of those libraries are optional, in that libvirt will use them where it detects them installed.

Looks like I'll need to explore MacPorts "variants" approach I've heard mention of. Not a stress. :)

[jclift@…]

This new version of the file declares the dependant libraries, plus uses variants (with sensible defaults) for everything that's optional.

In *theory* I think it's now good to go.

[ryandesign (Ryan Carsten Schmidt)]

Why supported_archs x86_64? What's the matter with this port on the i386, ppc and ppc64 architectures?

Your configure arguments --with-foo=no would be better written --without-foo.

I see you've added a lot of variants, but actually, the fewer variants a port has, the better. Many of the variants you've added, you've also made them defaults. Is there any reason why a user would want to disable them? If not, remove them and just make that the unconditional behavior of the port. The same goes for any remaining variants that merely twiddle a configure argument to enable a feature; if there's no added dependency (or if the added dependency is small), remove the variant and just add the dependency to the port directly.

What python does the python variant use? I notice it doesn't declare a dependency on any MacPorts python port. Most ports that have python parts have variants for each version of python in MacPorts. This is rather tedious but currently the best way.

The docs variant sets depends_build port:xhtml1 which overwrites the port's global pkgconfig build dependency; you would want to use depends_build-append in the variant instead, except that, as discussed above, you may want to delete the variant instead.

[jclift@…]

Hmmm, thinking about the supported_archs of x86_64, it's probably better to add the i386 version as well.

For the ppc and ppc64 variants, I didn't want to include them atm as I'm just not sure if they works. I don't have any ppc gear to test, and was thinking it better to not potentially introduce a broken port. There is a decent chance they'll work... but I just don't know. Is the best idea here to just drop the "supported_archs" keyword? (the MacPorts Guide doesn't mention it at all)

I'll redo the variants as being --without-foo versions instead, as you recommend, and rationalise/reduce the number where it makes sense to. Was obviously going for "everything as options", but that can be reduced, no stress. Definitely including the docs (aka xhtml1) is a good idea. :)

With python, I'm unsure. My understanding of the libvirt Python bindings is that they'll work with anything 2.x based, including the system provided ones. Guess I'd better look into making appropriate variants for each MacPort version.

[ryandesign (Ryan Carsten Schmidt)]

Yes, remove supported_archs, unless you know for a fact that something will not work on an architecture.

I have no doubt that libvirt's python support will work with a range of python versions, however, it would be improper for MacPorts to install files into Mac OS X's python, and if you're going to use a MacPorts python, you must ensure you use a specific one, and/or provide the variants to let a user choose.

[jclift@…]

Thanks Ryan.

This new version has:

• The sensible variants that were previously separate, now part of the normal build (including building docs).
• Separate python2x variants for each version libvirt supports (2.4-2.7).
• Supports +universal now, due to removal of supported_archs.

There is a specific override for the yajl port, so it's not used when building +universal, as that was otherwise failing.

Workable?

[jclift@…]

Oh, all of the "--with-foo=no" have been converted to "--without-foo" as well.

[jclift@…]

Additional capabilities added to the default build.

[jmroot (Joshua Root)]

r87930