Bug 553085 - publican clean_ids does not check whether it assigned a duplicate ID
publican clean_ids does not check whether it assigned a duplicate ID
Status: CLOSED ERRATA
Product: Publican
Classification: Community
Component: publican (Show other bugs)
1.6
All Linux
low Severity medium
: ---
: ---
Assigned To: Jeff Fearn
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-01-06 21:35 EST by Don Domingo
Modified: 2010-11-23 23:17 EST (History)
6 users (show)

See Also:
Fixed In Version: 1.4-1.fc12
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-01-31 20:14:39 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
a shortened version of the source for SystemTap Tapset Reference (610.00 KB, application/x-tar)
2010-01-06 21:35 EST, Don Domingo
no flags Details

  None (edit)
Description Don Domingo 2010-01-06 21:35:43 EST
Created attachment 382134 [details]
a shortened version of the source for SystemTap Tapset Reference

Description of problem:

When running 'publican clean_ids', it looks like publican assigns a new ID to each block tag based on information such as its parent tag, book title, chapter title, and nested <title> value. This is fine, except for two things:

- 'publican clean_ids' does not check whether it has assigned a non-unique ID. 

- as such, if another block tag is in the same chapter and has the same nested <title> value, it ends up with non-unique ID attributes, which fails validation and build.

Normally we wouldn't have sections in the same chapter sharing the same title, but clean_ids did this for <refsection> and <refsect1> tags (tried both). These tags are nested in <refentry>, and could be used for <title>Description</title>, <title>Values</title>, and the like. 

There could be numerous <refentry> items in a <chapter> or <reference>, all with their own <refsection>s or <refsect1>s for <title>Description</title>, <title>Values</title>, etc. This is the only instance I can think of where duplicate titles occur, but I think there may be other user cases.

Version-Release number of selected component (if applicable):

  publican-1.3-0.fc11.noarch

How reproducible:

  I tried it out using the attached book source, which contains a <reference> and numerous nested <refentry> blocks. 

Steps to Reproduce:
1. 'tar -xvf testbook.tar' ; 'cd SystemTap_Tapset_Reference'
2. 'publican build --formats=html --langs=en-US' -- build should be ok
3. 'publican clean' to remove temp XML and html files
4. 'publican clean_ids'
  
Actual results:
Running 'publican build --formats=html --langs=en-US' after clean_ids will fail, validation borks because of duplicated ID attributes assigned to <refsection>s. 


Expected results:

publican appends a unique number/string to each ID it assigns during 'publican clean_ids' (e.g. <section id="ch-ChapterOne-Title-123">). 

Additional info:
Comment 1 Jeff Fearn 2010-01-18 01:25:55 EST
Modified clean ID's to set the ID on the refnamediv instead of the refsect* tags, thus preventing ID clashes without removing links. 

workaround: none.
Comment 2 Fedora Update System 2010-01-28 21:05:15 EST
publican-1.4-1.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/publican-1.4-1.fc12
Comment 3 Fedora Update System 2010-01-28 21:06:34 EST
publican-1.4-1.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/publican-1.4-1.fc11
Comment 4 Fedora Update System 2010-01-31 20:13:22 EST
publican-1.4-1.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 5 Fedora Update System 2010-01-31 20:21:44 EST
publican-1.4-1.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.