|
Bugzilla – Full Text Bug Listing |
| Summary: | broken link in info:libc | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.2 | Reporter: | Christopher Yeleighton <giecrilj> |
| Component: | Development | Assignee: | Richard Biener <rguenther> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | ke |
| Version: | Final | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | openSUSE 11.2 | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
I think gcc must also provide entry points (anchors) without version number. Entry points in gcc do not have version numbers. Paths have. Another example of this at (libc)Adding another Service to NSS. I'm not sure how to add unversioned entries. Using a symlink and the usual
%install_info --info-dir=%{_infodir} %{_infodir}/cpp.info.gz will not work,
as the file will still contain
START-INFO-DIR-ENTRY
* cpp-4.5: (cpp-4.5). The GNU C preprocessor.
END-INFO-DIR-ENTRY
If I add --name and --description arguments I am able to create an
unversioned entry for the same file, but I can't figure out a way to
just delete the unversioned entry but not the versioned one at the
same time.
If you delete the unversioned entry, delete the versioned ones as well. Not having the unversioned entry means not having an entry for any version. Deinstalling the package with the versioned entry will also cause the unversioned entry to be removed. That sounds like what should happen (fun things may happen when updating the unversioned package though - we'll see). Deinstalling cpp44 does not remove /usr/bin/cpp. Why should it be any different with documentation? Because install-info removes all entries that refer to the specified file (and there is no way to only remove one of the entries). If you have cpp45 installed, the unversioned directory entry will point to cpp45.info, so it will be unaffected by removing cpp44. Or is it a different scenario you are trying to address? An obvious, although rather cumbersome, solution would be to make cpp.info a regular info file where each node is a redirect to the respective versioned node. This would create only a slight annoyance to the reader. Failing that, even if the directory entry is gone, the hyperlinks in other info files will still work, even though the symbolic link will not have an entry in the info directory. And with the symbolic link present, I guess the info browser would be smart enough to find cpp.info when requested. As a last resort, there could be some SuSEconfig.info script to keep the links right. Only installing gcc-info will provide unversioned links. gcc-info will link to the distribution default versioned versions (gcc45-info). Installing or removing gcc44-info will not affect the unversioned link. (In reply to comment #10) > Only installing gcc-info will provide unversioned links. gcc-info will link > to the distribution default versioned versions (gcc45-info). Installing or > removing gcc44-info will not affect the unversioned link. This comment directly contradicts comment #6. I am confused. (In reply to comment #11) > (In reply to comment #10) > > Only installing gcc-info will provide unversioned links. gcc-info will link > > to the distribution default versioned versions (gcc45-info). Installing or > > removing gcc44-info will not affect the unversioned link. > > This comment directly contradicts comment #6. I am confused. I don't see how. What remains to be seen is what happens on distribution upgrade when the system gcc is updated and gcc-info is installed. (In reply to comment #12) > > This comment directly contradicts comment #6. I am confused. > > I don't see how. > Deinstalling the package with the versioned entry will also cause the unversioned entry to be removed. Removing gcc44-info removes the entry cpp from the info directory (info). >Installing or removing gcc44-info will not affect the unversioned link. Removing gcc44-info leaves the file cpp.info intact. So, indeed, no contradiction: the entry goes but the file remains. > > What remains to be seen is what happens on distribution upgrade when > the system gcc is updated and gcc-info is installed. Updating gcc should create the file cpp46.info and register it in the info directory. Installing gcc-info should create the file cpp.info and register it in the info directory. Updating gcc should trigger an update of gcc-info, otherwise things could go stale. Removing gcc46-info should trigger an update of gcc-info as well. If this would leave gcc-info without any supporting package, gcc-info should be removed along with it. Fixed for factory. ditto for help:/kioslave/info/index.html |
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; pl-PL; rv:1.9.1.11) Gecko/20100714 SUSE/3.5.11-0.1.1 Ant.com Toolbar 2.0.1 Firefox/3.5.11 Hyperlinks from libc to gcc do not have the gcc version number and thus do not correspond to resources. Reproducible: Always Steps to Reproduce: 1. Visit <URL:info:/libc/Header%20Files> 2. Follow the hyperlink to [Header Files]. Actual Results: 1. For more information about the use of header files and `#include' directives, [Header Files] (cpp.info)Header Files. 2. KDE Info Pages Viewer Error No info page for topic "cpp.info" found. You may find what you are looking for at the cpp.info manpage. Expected Results: 2. <URL:info:/cpp-4.4.info/Header%20Files> Note that there are several ways to address this problem: info: The info mechanism could be instructed to automatically detect version number. (Note that this already happens for the info executable, albeit in a limited way: { info 'cpp'; } works, { info '(cpp)'; } fails. glibc-info: The straightforward soultion is to update the hyperlinks with version numbers. gcc-info: Provide generic hyperlinks, e.g. { ln '-s' 'cpp-4.4.info.gz' 'cpp.info.gz'; }. This already happens for shared libraries. This action could also be performed by SuSE config. gcc44-info: Do not use versioned document names or provide the links as above.