[coreutils] require glibc-devel to prevent broken links in coreutils info manual (#959697)

[Reindl Harald]

Am 17.05.2013 12:35, schrieb Ondrej Vasik:
>> In that case, glibc maintainers need to re-consider their claim that it
>> is only material for developers & put it in glibc-common or a glibc-docs
>> package instead of the -devel package
> 
> That's what the glibc maintainers proposed as longer term solution for their upstream todo list - split their info doc into strictly devel part and "general purpose" part. This may need some time, though (and even then, it will probably need some adoption, as it will probably be named differently, so links may break again)...
> 
> Require glibc-devel in coreutils means + ~1M to default minimal installation size. Not much, but not good practice, I agree. I may go with coreutils-infodoc (or something like that) subpackage (keeping just basic manuals in main package and additional docs separately). This will bring back the "granularity" instead of hard dependency in the minimal install package. Any thoughts?

no, it pulls "glibc-headers" and "kernel-headers" too
which are in summary 5.9 MB and around 120 MB on our
virtual infrastructure

one of the most often happening packaging error is not look
at the dependency chain and what 5 or 10 MB mean for larger
environments

and finally mostly missed is the "random dependency chain"
if one or more of the implicit pulled packages are raising
their deps too fro whatever reasons which will lead in case
of devel-packages easily to pull GCC and a ton of libs by
accident and no developer takes notice because this cases
are not tested well and the apckages are on their machines

with relaxed dependencies and manpages splitted at all to
subpackages a fedora server would be easily stripped down
to 600-700 MB instead around 1 GB

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130517/5a4b9729/attachment.sig>