Bug 553085 - publican clean_ids does not check whether it assigned a duplicate ID
Summary: publican clean_ids does not check whether it assigned a duplicate ID
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Publican
Classification: Community
Component: publican
Version: 1.6
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Jeff Fearn 🐞
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-01-07 02:35 UTC by Don Domingo
Modified: 2010-11-24 04:17 UTC (History)
6 users (show)

Fixed In Version: 1.4-1.fc12
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-02-01 01:14:39 UTC


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

Description Don Domingo 2010-01-07 02:35:43 UTC
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 06:25:55 UTC
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-29 02:05:15 UTC
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-29 02:06:34 UTC
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-02-01 01:13:22 UTC
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-02-01 01:21:44 UTC
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.