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(a)redhat.com >
> > > > > 2013/5/17 Ondrej Vasik < ovasik(a)fedoraproject.org >
> > > > >
> > > > >
> > > > > commit ed5396d91e0032fa7cbfd6cb0bde3d7850aba790
> > > > > Author: Ondřej Vašík < ovasik(a)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