On Sat, Mar 2, 2013 at 9:21 PM, Kevin Kofler <firstname.lastname@example.org>
Jon Ciesla wrote:
> I see no reason not to keep dietlibc around for development use, but I'd
> 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).
Excellent, can you file all of this as a BZ against dietlibc so we can track it, and not rely on my imperfect memory? I don't want to miss a thing*.
devel mailing list