Making Packager-Friendly Software, Part 2 (O'ReillyNet) [LWN.net]

O'ReillyNet continues making software that is easy to package, with a look at dependencies, configuration files and more. "Many packaging systems (including pkgsrc) let you build packages as a regular user and require only superuser privileges to install them (to have the right permissions, ownerships, setuid flags, and so on). Therefore, you should make sure that your program builds correctly without superuser privileges to ease the packaging task. I can't think of an example in which a program requires full privileges to build."

to post comments

Making Packager-Friendly Software, Part 2 (O'ReillyNet)

Posted Apr 30, 2005 9:54 UTC (Sat) by tzafrir (subscriber, #11501) [Link] (4 responses)

I'm not sure I agree with his first example:

If your library is linked with libssl, any program linked with your library is lined with libssl as well. This is a dependency. No matter how hard you try to hide it, it still is.

If you switch in a later version of the library from openssl to gnu tls, you'll probably break binary compatibility and require a rebuild of any program using the library.

Later when he talks about gnu make incomatibilities: He probably spent too much time with automake-generate makefiles. GNU make has some pretty useful features that are unused by automake to enable cross-make compatibility. Never mind the fact that just about everyone has gmake around.

Making Packager-Friendly Software, Part 2 (O'ReillyNet)

Posted Apr 30, 2005 14:15 UTC (Sat) by ballombe (subscriber, #9523) [Link]

The article is right, this is a known bug in pkgconfig.
See http://www.debconf.org/debconf4/talks/dependency-hell/ind...

> If your library is linked with libssl, any program linked with your library is lined with libssl as well. This is a dependency. No matter how hard you try to hide it, it still is.

Not really. The program might only depend on some entry points in the vfs library. Whether the entry points call entry points in libssl or libgnutls is not its business.

This is only an indirect dependency. Assuming the vfs library depend on libssl, there is no need to mention it, and it might be downright harmful.

Making Packager-Friendly Software, Part 2 (O'ReillyNet)

Posted Apr 30, 2005 16:03 UTC (Sat) by farnz (subscriber, #17727) [Link] (2 responses)

If my program is an abstraction service that allows you to fetch data via HTTP, HTTPS or FTP (all you do is pass in an opaque URL, and get data back), changing from OpenSSL to GnuTLS should not change binary compatibility. After all, the API I've described is simple (pass in a URL, get a bytestream back); the SSL stuff is all hidden away.

As it's only an indirect dependency, your program should not know about it; I can extend the interface without breaking backwards compatibility (add a function that takes an opaque URL, a byte range, and returns a bytestream), so why can't I change my internal dependencies?

Making Packager-Friendly Software, Part 2 (O'ReillyNet)

Posted May 3, 2005 14:26 UTC (Tue) by tzafrir (subscriber, #11501) [Link] (1 responses)

The interface you describe is a TCP port. It is not dynamic linking. Thus the library is indeed irrelevant in the case you describe. But this is not so in the article.

Making Packager-Friendly Software, Part 2 (O'ReillyNet)

Posted May 3, 2005 14:51 UTC (Tue) by farnz (subscriber, #17727) [Link]

So, a call to the C++ function "istream openResource(const string URL);" is a TCP socket? I could open a file, do a HTTP transaction, handle HTTPS, or any one of a number of tricks behind the scenes to make my library do the work for you. Whatever happens, all you care about is that my function doesn't change, not that the underlying implementation (OpenSSL or GnuTLS for SSL, fork and call wget or use the OPP library, whatever) doesn't change.