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

Ondrej Vasik ovasik at redhat.com
Fri May 17 10:22:09 UTC 2013


> 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). Duplicating nodes as downstream patch is no go for me - hard to maintain and unacceptable upstream. Broken links are better than that - and Require: glibc-devel is more temporary (and of course not perfect) solution until more sane approach will be possible.

Greetings,
         Ondrej


More information about the devel mailing list