[WIP] New package: libircclient-1.10

[maciozo]

I'm not sure if I'm handling the .so files correctly, so any guidance would be appreciated.

I've tested the library only (running irctest.c) on x86_64-glibc.

[maciozo]

There's a problem when cross-compiling to ppc64le - ldd isn't able to recognise the format of the .so file.

[maciozo]

Added libircclient.so.1 to common/shlibs

[maciozo]

I've put in a feature request for a pkg-config file from the developer, but I don't expect results

[pullmoll]

Don't use tabs except before the first non-blank character of a line.

[Johnnynator]

I highly doubt that the libc devel packages are even needed at runtime, these 4 lines can most likely be removed.

[maciozo]

I highly doubt that the libc devel packages are even needed at runtime, these 4 lines can most likely be removed.

I'm going by what the libircclient docs say. The way I understand it, those are runtime dependancies.

[pullmoll]

Also vmove "usr/lib/*.so" because these will be used by packages depending on this one and are generally not required in the libircclient package. There only the versioned *.so.* files should reside.

[maciozo]

Won't this break the symlink libircclient.so.x -> libircclient.so for users who don't install the devel package?

[pullmoll]

No, it's the other way round, or vice-versa: libircclient.so is a symbolic link to libircclient.so.x. Packages linking against libircclient.so will thus resolve that symlink to the numbered so.
And common/shlibs is Void's way to resolve a dependency from a numbered so back to the library (and version), which then saves you from explicitly defining the required libraries in depends=….

[maciozo]

Does that mean I have to rename libircclient.so to libircclient.so.x in the do_install() of libircclient?

[maciozo]

Just so we're clear, the makefile produces libircclient.so, not libircclient.so.x. My experience with libraries is minimal, so I don't know if this is how it's supposed to be done. If not, I can just patch it to produce libircclient.so.x instead.

[pullmoll]

For srcpkgs/libircclient/patches/build_shared_and_static.patch you should use unified diff format, i.e. diff -u, because all our own patches use that.

[pullmoll]

I tend to think if you just remove do_install() and let xbps-src do its job in the default gnu-configure build style it should work. All the things you did seem way too complicated.

[maciozo]

@pullmoll

I tend to think if you just remove do_install() and let xbps-src do its job in the default gnu-configure build style it should work. All the things you did seem way too complicated.

Removing do_install() fails with:

=> libircclient-devel-1.10_1: running pkg_install ...
mv: cannot stat '/destdir//libircclient-1.10/usr/share/doc/libircclient/*': No such file or directory
=> ERROR: libircclient-devel-1.10_1: pkg_install: 'mv ${_destdir}/$files ${_pkgdestdir}/${_targetdir}' exited with 1
=> ERROR:   in _vmove() at common/environment/setup/install.sh:232
=> ERROR:   in _noglob_helper() at common/environment/setup/install.sh:12
=> ERROR:   in pkg_install() at srcpkgs/libircclient-devel/template:28

With template:28 being vmove usr/share/doc/${sourcepkg}/* in libircclient-devel_package().pkg_install()

Also removing pkg_install() fails with:

=> libircclient-devel-1.10_1: running pre-pkg hook: 99-pkglint ...
=> ERROR: libircclient-devel-1.10_1: PKGDESTDIR is empty and build_style != meta
=> ERROR: libircclient-devel-1.10_1: cannot continue with installation!

[maciozo]

I have no idea what the shlibs conflict is about. The file should be identical to the current master, with libircclient appended.

[pullmoll]

I'll take a closer look at this.

[pullmoll]

This template works for me. You need to replace 1.10 with @version@ in files/libircclient.pc so that the sed can replace it with the current $version and you don't have to update that file for a new version.

It seems you merged master to your branch without --rebase which is why now common/libs conflicts. Perhaps save your files, reset your branch and force push to this PR after adding the files back.

Oh, I didn't try to build the static library. Do you really need it?

[maciozo]

Sorry, @pullmoll, I was rather busy lately.

Pardon my ignorance, but what is the point in having a non-devel package, if only the devel package contains the .so file? Any program dynamically linked to libircclient would have to have libircclient-devel as a runtime dependancy, no? Hence why I put the dynamic library in the normal package, and the static in the devel package.

[Duncaen]

.so is a symlink to the versioned /usr/lib/libircclient.so.1.

xbps-query -Rf libircclient-devel | grep \\.so
/usr/lib/libircclient.so -> /usr/lib/libircclient.so.1

Your programs link against the versioned library, the compiler uses the unversioned symlink to "discover" the default version it should link against.

[pullmoll]

Take a look at other library providing packages and how they always move the usr/lib/*.so files into the <pkgname>-devel subpackage and the usr/lib/*.so.* files into the <pkgname>-libs subpackage, if it exists, or leave them in the main package, if that is the library. Some packages may have a main package containing binaries (utils, tools) and a seperate <pkgname>-libs package with just the SOLIBS.

Now some package linking against libircclient will have makedepends="… libircclient-devel …" in its template.
When the linking is done, the resulting binary (or dependent library) will really link against e.g. /usr/lib/libircclient.so.1 (not /usr/lib/libircclient.so) and xbps-src will, by looking up that numbered SOLIB in common/shlibs find that actually libircclient-1.10_1 (or newer) is the dependency to include.

This allows xbps-src to automatically resolve dependencies and, most importantly, detect if and when a new version of a <libname>.so.# requires a revision bump of packages depending on it.

Imagine libircclient will be updated and an ABI incompatibility requires an SONAME bump to libircclient.so.2. Now xbps-src will detect that fact, tell you about it, and also tell which dependencies need a rebuild.

HTH

[maciozo]

Thanks, @Duncaen and @pullmoll.

Is it not reasonable to include a static library as well though? I see that some libraries include them, but I don't really know when it would be appropriate to do so. libircclient is pretty small, so it doesn't seem too unreasonable that a developer would want to statically link it.

[Duncaen]

If you want to statically link it, you use libircclient-devel, which contains the static library and your resulting binary will not depend on either libircclient or libircclient-devel.
The static library is in the -devel package, because you don't need it at runtime, only while developing/building your programs.

Edit: In general there is no rule about including static libraries or not, this depend on the person packaging or the default of the project that is being packaged.