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

[Ondrej Vasik]

> On Fri, May 17, 2013 at 06:22:09AM -0400, Ondrej Vasik wrote:
> > > On Fri, May 17, 2013 at 04:25:43AM -0400, Ondrej Vasik wrote:
> > > > > 2013/5/17 Ondrej Vasik < ovasik at redhat.com >
> > > > > > 2013/5/17 Ondrej Vasik < ovasik at fedoraproject.org >
> > > > > > 
> > > > > > 
> > > > > > commit ed5396d91e0032fa7cbfd6cb0bde3d7850aba790
> > > > > > Author: Ondřej Vašík < ovasik at redhat.com >
> > > > > > Date: Fri May 17 09:21:51 2013 +0200
> > > > > > 
> > > > > > require glibc-devel to prevent broken links in coreutils info
> > > > > > manual
> > > > > > (#959697)
> > > > > > 
> > > > > > I don't think having glibc-devel installed by default will make it.
> > > > > > Also you bugzilla number is wrong. (unrelated).
> > > > > 
> > > > > Thanks, fixed the typo in changelog...
> > > > > Why do you think it will not make it work? Glibc info manuals are
> > > > > there,
> > > > > so
> > > > > the broken links should be prevented by this.
> > > > > The general idea of splitting packages is that you can install one
> > > > > that
> > > > > is
> > > > > required and not another that is optional.
> > > > > As coreutils is required by default, that's defeat the point to even
> > > > > have
> > > > > this split made. Because both will be required.
> > > > > 
> > > > > My understanding is that libc*.info should be moved to the main glibc
> > > > > instead
> > > > > as most info file belong to the main package.
> > > > > One that doesn't want to install the documentation can still install
> > > > > with
> > > > > rpm
> > > > > nodocs
> > > > 
> > > > That's what I suggested to glibc maintainers - to move it to
> > > > glibc-common,
> > > > so everything would be fine. They insist that this info is intended for
> > > > developers, therefore I have two options - require glibc-devel (just
> > > > ~1M,
> > > > most of the other files are links or small files) or live with broken
> > > > links (and WONTFIX that). You are right about nodocs, though.
> > > 
> > > Or better still, fix the coreutils user-targetted docs, to not refer to
> > > glibc's developer-targetted docs. Coreutils docs could just include info
> > > on how to set the TZ variable, instead of punting the task to glibc's
> > > developer docs.
> > 
> > Well, I don't think glibc info doc has only developer-targetted info -
> > that's the issue - there are more things useful to regular experienced
> > users (like regexps info, locales info).
> 
> 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?

Ondrej