Arch Linux

dimich

Member

From: Kharkiv, Ukraine

Registered: 2009-11-03

Posts: 713

Arch policy for features of libraries in official repo

Many libraries allow to switch one or another feature at build time. Is there any policy or guideline defining what features should™ be enabled or disabled in libraries provided by official repo?

For example, I develop an application using libcoap. There is official extra/libcoap package. However, it provides only headers, static library and cmake metadata. No shared objects, no pkg-config metadata, no executables for debug.
It's not a show stopper, I built custom package with all required features enabled. However, it would be nice to have all that in a single package from official repo.

Similar but more complex story with wolfssl. There is extra/wolfssl, but it lacks support of some features like DTLS 1.3. I could build custom package, but I have to change prefix to something else than /usr/ or change basenames to avoid conflicts with existing library files. Or use conflicts= and provides= in custom PKGBUILD and replace official package because wolfss is an implicit dependency for some other official packages I have installed. Wolfssl has BUILD_DISTRO option (--enable-distro) but it is not enabled in the package for some reason.

Would it be too bold to create feature requests for such packages if requested features aren't needed by any other official package? Or should I continue to use custom modified packages installed in parallel or instead of official ones?

seth

Member

From: Won't reply 2 private help req

Registered: 2012-09-03

Posts: 76,933

Re: Arch policy for features of libraries in official repo

"Upstream defaults"
https://github.com/obgm/libcoap/blob/0b … ts.txt#L28
https://github.com/wolfSSL/wolfssl/blob … s.txt#L712

Since libcoap isn't packaged to serve as dependency for another package (but as feature) it's probably fair to ask the defaults to be changed if they render the package useless - though you'll likely be asked to file an upstream bug to change the defaults there first.

wolfssl exists as dependency for other packages but TLS has more to do w/ the particular connection, not the client.
No idea why it's disabled by default but the package enables some protocols/algorithms, https://gitlab.archlinux.org/archlinux/ … =heads#L31
=> ask

---

How to upload text · How to boot w/o GUI · Disable Windows Fast-Start! · Fix your xinitrc

dimich

Member

From: Kharkiv, Ukraine

Registered: 2009-11-03

Posts: 713

Re: Arch policy for features of libraries in official repo

Thanks for the reply, seth.

Some thoughts out loud below.

As I understand, Arch doesn't divide library packages to "runtime" and "dev" parts like Debian do. A sole package usually contains shared objects, headers and linker metadata, so it can be used as both runtime and make dependency, at the price of redundant headers/metadata installed even if a library is used as runtime dependency only.

If upstream desided that some feature should not be enabled by default, unlikely it will be enabled in the package unless required by other package.
A library may enable or disable some features in autodetect script, so whether a feature is enabled depends on build environment and build order. Moreover, an application may enable or disable a feature at build time depending on existing libraries and their enabled features, so that feature will be disabled in application as well.

In software development it's convenient to test and debug certain parts of software directly on host. I thought it would be easier to use already installed libraries from official repos. It turned out that it isn't