Jon Ciesla wrote:
I see no reason not to keep dietlibc around for development use, but
rather see packages use glibc.
We agree then. But if we want to keep dietlibc, it needs to be fixed to
comply with the packaging guidelines and best practices, i.e.:
* Shared library build needs to be enabled. I see no reason to build this
library as static only as Enrico is doing. We tolerate this where upstream
does not support shared builds at all, but this is not the case here.
* The main package should contain the shared library (and the documentation
that's relevant at runtime, in particular COPYING) only. Right now it
contains some stuff which probably belongs into -devel.
* The main package must not require -devel as it does now.
* The -devel package should not contain the static library, which should
instead be in a -static subpackage.
* The -lib package (which is currently not built by default, it contains the
shared library if you enable shared build) should simply be the main
package. It doesn't make sense to have a -lib subpackage of a library.
* The -header subpackage should really be called -headers (There's more than
one header! And it'd also be consistent with glibc.) or folded into -devel
(though then it can't be noarch anymore).