Bug 642127

Summary:	[l10n] %changelog doesn't follow packaging Version Release format with publican 'package' action
Product:	[Community] Publican	Reporter:	sandeep shedmake <sshedmak>
Component:	publican	Assignee:	Jeff Fearn 🐞 <jfearn>
Status:	CLOSED CURRENTRELEASE	QA Contact:	tools-bugs <tools-bugs>
Severity:	medium	Docs Contact:
Priority:	low
Version:	2.3	CC:	ankit, ccheng, dlackey, fche, jfearn, mhideo, mmcallis, mospina, noriko, publican-list, rlandman, xhuang
Target Milestone:	3.0
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	3.0.0	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-10-31 03:11:30 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description sandeep shedmake 2010-10-12 05:50:29 UTC

Description of problem:
$publican package --brew --lang=<XX-YY>, 
creates *.src.rpm first locally at ~/Book_Name/tmp/rpm location; and later is uploaded to the brew server and builds it (a taskID over brew server is created) and respective RPMs are generated.

Problem is, %changelog in *.spec (generated at ~/Book_Name/tmp/rpm/ location) doesn't follow packaging Version Release format.

Version-Release number of selected component (if applicable):
publican-2.2-0.fc13.noarch

How reproducible:
always

Steps to Reproduce:
1. Checkout a book (from upstream repository).
2. Complete the translations (*.po) & commit back translated content.
3. Initiate 'publican package --brew --lang=<XX-YY>' 
4. Follow the respective ~taskID created over brew server (till build completes successfully).
5. When build completes successfully (and resultant RPMs created), observe the Changelog for not following packaging Version Release format.

Actual results:
%changelog doesn't follow packaging Version Release format.

Expected results:
%changelog should follow packaging Version Release format.

Additional info:
Workaround for %changelog to follow packaging Version Release format has been tried for book|title =Installation_Guide, productname =Red Hat Enterprise Linux, productnumber =6 & edition =1.0 (with following steps):

(1) Update, ~/en-US/Revision_History.xml for
<revnumber>...</revnumber> section.

Content within <revnumber>...</revnumber> section goes into "%changelog" 
of Red_Hat_Enterprise_Linux-Installation_Guide-6-web-<XX-YY>.spec.

(2) ~/LANG/Book_Info.po --> "Project-Id-Version: 2", 
as it decides the value for "Release" variable/key in 
Red_Hat_Enterprise_Linux-Installation_Guide-6-web-<XX-YY>.spec.

(3) svn commit -m "Project-Id-Version update" <XX-YY>/Book_Info.po

(4) Run $publican package --scratch --lang=<XX-YY>.

wherein '--scratch' creates following locally on your machine
(doesn't upload to brew server) at ~/Installation_Guide/tmp/rpm/
location:

Red_Hat_Enterprise_Linux-Installation_Guide-6-web-<XX-YY>-BookVersion-BookRelease.el5.src.rpm
Red_Hat_Enterprise_Linux-Installation_Guide-6-web-<XX-YY>-BookVersion-BookRelease.tgz
Red_Hat_Enterprise_Linux-Installation_Guide-6-web-<XX-YY>.spec

NOTE:
%changelog in 
Red_Hat_Enterprise_Linux-Installation_Guide-6-web-<XX-YY>.spec should 
follow Version Release format all the time.

(5) Now if satisfied with --scratch build, brew the document by initiating following:
$publican package --brew --lang=<XX-YY>


Sample build, where %changelog follows Version Release format
https://brewweb.devel.redhat.com/buildinfo?buildID=145892 
(for example sake only)

Sample builds, where %changelog DOESN'T follow Version Release format:
https://brewweb.devel.redhat.com/buildinfo?buildID=146046
https://brewweb.devel.redhat.com/buildinfo?buildID=145988
(for example sake only)

Comment 1 Ruediger Landmann 2010-10-12 06:57:27 UTC

Summarizing:

When Publican packages translated documents, it takes the release number from LANG/Book_Info.po file, but creates the %changelog in the spec file from Revision_History.xml. 

The release numbers are therefore unlikely to match, and the package therefore won't pass rpmlint.

Comment 2 Jeff Fearn 🐞 2010-10-18 03:03:36 UTC

IMHO the work around is not worth the risk. This is not an issue that would block releasing packages and it has the potential to cause bigger problems than it solves, particularly given the large number of translators who are not technically competent at maintaining packages.

The problem here is maintaining language revision history across multiple source language updates.

I propose the following solution:

1: Each language has it own <lang-loc>/Revision_History.xml file. This file would be structured the same as the current source language file, but it would only contain language specific changes.

2: When the PO files for a language are updated Publican would:
A: reset the release number in the Book_Info.po file to zero,
B: add an entry to the language Revision_History.xml file with the new release number stating that the PO files were updated.

(The string for the entry could be translated as part of Publican so as to not require this entry to be translated every time.)

3: When a translator updates the translation, they would bump the revision in Book_Info.po and add a new entry to their language Revision_History.po file with a summary of their changes.

4: When building translated books, Publican would merge the source and translation Revision Histories.

This would allow translation history to be properly maintained, including the author or authors responsible for it, and allow full and proper change logs to be generated for packaging and use in the generated content.

Comments welcome!

Cheers, Jeff.

Comment 3 sandeep shedmake 2010-10-18 03:56:47 UTC

From Comment 2,

Yes, the proposal looks good.

Comment 4 Jeff Fearn 🐞 2010-10-18 04:22:14 UTC

Hi, can I get some feedback on Comment #2 from the translation leadership? It will require some training and ongoing management to make it work usefully.

Thanks, Jeff.

Comment 5 sandeep shedmake 2010-10-22 08:58:57 UTC

From Comment #4,

For those CC'ed in this bug:
if there are any other alternatives against the proposal suggested by Jeff (in Comment #2), please mention in this bug itself.

Your valuable feedback awaited.

-Sandeep

Comment 6 sandeep shedmake 2010-10-25 10:54:03 UTC

Any action/feedback/comment from the translation leadership?

Or 

Is it assumed that Jeff's proposal (see Comment #2) is accepted unanimously (which is really good with respect to maintaining language revision history across multiple source language updates)  by the translation leadership.

Comment 7 Ankit Patel 2010-10-25 11:38:42 UTC

Hi Sandeep,

Thanks for bringing this issue, as I have tried to raise it in the beginning itself when publican was introduced.

In my opinion following should be the format of srpms and ChangeLogs.

...FOR_ENGLISH
Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-1.el5.src.rpm
Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-2.el5.src.rpm
Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-3.el5.src.rpm
...
CHANGELOG...
1.0-1
1.0-2
1.0-3

...FOR_LOCALIZED_BUILDS
Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-1-de_DE-1.0.el5.src.rpm
Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-1-de_DE-1.1.el5.src.rpm
Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-1-de_DE-1.2.el5.src.rpm
...
Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-2-de_DE-1.0.el5.src.rpm
Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-2-de_DE-1.1.el5.src.rpm
Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-2-de_DE-1.2.el5.src.rpm
...
Red_Hat_Enterprise_Linux-6-Installation_Guide-2.0-1-de_DE-1.0.el5.src.rpm
Red_Hat_Enterprise_Linux-6-Installation_Guide-2.0-1-de_DE-1.1.el5.src.rpm
Red_Hat_Enterprise_Linux-6-Installation_Guide-2.0-1-de_DE-1.2.el5.src.rpm
...
Red_Hat_Enterprise_Linux-6-Installation_Guide-2.0-2-de_DE-1.0.el5.src.rpm
Red_Hat_Enterprise_Linux-6-Installation_Guide-2.0-2-de_DE-1.1.el5.src.rpm
Red_Hat_Enterprise_Linux-6-Installation_Guide-2.0-2-de_DE-1.2.el5.src.rpm
...

CHANGELOG...
1.0-1-de_DE-1.0
1.0-1-de_DE-1.1
1.0-1-de_DE-1.2
...


Thanks!
Ankit

Comment 8 sandeep shedmake 2010-10-25 13:05:00 UTC

(In reply to comment #7)

<snip/> 
> .. format of srpms and ChangeLogs 
<snip/> 

> 
> ...FOR_LOCALIZED_BUILDS
> Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-1-de_DE-1.0.el5.src.rpm
> Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-1-de_DE-1.1.el5.src.rpm
> Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-1-de_DE-1.2.el5.src.rpm
> ...
> Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-2-de_DE-1.0.el5.src.rpm
> Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-2-de_DE-1.1.el5.src.rpm
> Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-2-de_DE-1.2.el5.src.rpm
> ...
> Red_Hat_Enterprise_Linux-6-Installation_Guide-2.0-1-de_DE-1.0.el5.src.rpm
> Red_Hat_Enterprise_Linux-6-Installation_Guide-2.0-1-de_DE-1.1.el5.src.rpm
> Red_Hat_Enterprise_Linux-6-Installation_Guide-2.0-1-de_DE-1.2.el5.src.rpm
> ...
> Red_Hat_Enterprise_Linux-6-Installation_Guide-2.0-2-de_DE-1.0.el5.src.rpm
> Red_Hat_Enterprise_Linux-6-Installation_Guide-2.0-2-de_DE-1.1.el5.src.rpm
> Red_Hat_Enterprise_Linux-6-Installation_Guide-2.0-2-de_DE-1.2.el5.src.rpm
> ...


productname =Red_Hat_Enterprise_Linux, 
productnumber =6
..
..
Hmn, format of the srpm (hope rpmlint remains silent). Thoughts?

> 
> CHANGELOG...
> 1.0-1-de_DE-1.0
> 1.0-1-de_DE-1.1
> 1.0-1-de_DE-1.2
> ...

item 4: of the proposal (in Comment #2) seems taking shape. Thoughts?


item 4:
When building translated books, Publican would merge the source and
translation Revision Histories.

Comment 9 Jeff Fearn 🐞 2010-10-26 05:23:40 UTC

(In reply to comment #7)
> Hi Sandeep,
> 
> Thanks for bringing this issue, as I have tried to raise it in the beginning
> itself when publican was introduced.
> 
> In my opinion following should be the format of srpms and ChangeLogs.
> 
> ...FOR_ENGLISH
> Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-1.el5.src.rpm
> Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-2.el5.src.rpm
> Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-3.el5.src.rpm
> ...
> CHANGELOG...
> 1.0-1
> 1.0-2
> 1.0-3
> 
> ...FOR_LOCALIZED_BUILDS
> Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-1-de_DE-1.0.el5.src.rpm
> Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-1-de_DE-1.1.el5.src.rpm
> Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-1-de_DE-1.2.el5.src.rpm
> ...
> Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-2-de_DE-1.0.el5.src.rpm
> Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-2-de_DE-1.1.el5.src.rpm
> Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-2-de_DE-1.2.el5.src.rpm
> ...
> Red_Hat_Enterprise_Linux-6-Installation_Guide-2.0-1-de_DE-1.0.el5.src.rpm
> Red_Hat_Enterprise_Linux-6-Installation_Guide-2.0-1-de_DE-1.1.el5.src.rpm
> Red_Hat_Enterprise_Linux-6-Installation_Guide-2.0-1-de_DE-1.2.el5.src.rpm
> ...
> Red_Hat_Enterprise_Linux-6-Installation_Guide-2.0-2-de_DE-1.0.el5.src.rpm
> Red_Hat_Enterprise_Linux-6-Installation_Guide-2.0-2-de_DE-1.1.el5.src.rpm
> Red_Hat_Enterprise_Linux-6-Installation_Guide-2.0-2-de_DE-1.2.el5.src.rpm
> ...
> 
> CHANGELOG...
> 1.0-1-de_DE-1.0
> 1.0-1-de_DE-1.1
> 1.0-1-de_DE-1.2

You haven't defined where the NVR components start and end, so it requires guessing where they are.


Guessing NVR for Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-3.el5.src.rpm:

N: Red_Hat_Enterprise_Linux-6-Installation_Guide
V: 1.0
R: 3.el5

This will work, but doesn't seem to gain us anything.

Guessing NVR for Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-1-de_DE-1.0.el5.src.rpm:

N: Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0
V: 1-de_DE
R: 1.0.el5

This is wrong, you can't install multiple languages, but you can install multiple versions of a book in one language for a single product version. Both of these are unacceptable.

N: Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-1
V: de_DE
R: 1.0.el5

This is wrong, you can't install multiple languages, but you can install multiple versions of a book in one language for a single product version. Both of these are unacceptable.

N: Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-1-de_DE
V: 1.0.el5
R:

This is wrong.

Assuming you fix the V & R issues above, the other flaw persists. If you base the translated package name (N) on the English revision (pubsnumber), then you can have multiple versions of a translated book installed, for a single product version, which is unacceptable.

e.g. having both the following packages installed would be a huge bug:

Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-1-de_DE-1.2.el5.src.rpm
Red_Hat_Enterprise_Linux-6-Installation_Guide-1.0-2-de_DE-1.0.el5.src.rpm

Comment 10 sandeep shedmake 2010-10-28 06:06:59 UTC

(In reply to comment #4)
> Hi, can I get some feedback on Comment #2 from the translation leadership? It
> will require some training and ongoing management to make it work usefully.
> 
> Thanks, Jeff.

Hi All,

Any suggestions on how this bug should move ahead; probably with the implementation of proposal in Comment #2 ?

I mean, if there are no possible flaws with the proposal (in Comment #2), then proposal could be implemented and made available in future(estimated) release of publican.


Regards,
Sandeep

Comment 11 Jeff Fearn 🐞 2010-12-08 04:15:02 UTC

FYI I have emailed an RFC for a proposed solution to the publican list.

https://www.redhat.com/archives/publican-list/2010-December/msg00001.html

Comment 12 Jeff Fearn 🐞 2010-12-17 03:22:25 UTC

Added functionality to allow translations to carry their own Revision_History.xml file, which is merged with source language version when building.

Added functionality to update translation Revision_History.xml file when update_po file is run for a language.

Removed old behaviour of using Book_Info.po file for translation version.

PUG updates required to document new behaviour.

Fixed in revision 1696

Comment 15 sandeep shedmake 2011-11-14 03:08:12 UTC

Is the fix available in publican-2.8-1 release ?

Comment 16 sandeep shedmake 2011-11-14 03:12:01 UTC

(In reply to comment #15)
> Is the fix available in publican-2.8-1 release ?

Please, disregard Comment 15;  Target Milestone is 3.0.

Comment 17 Michael Hideo 2012-06-08 02:04:36 UTC

create book with at least 1 translation, in that language directory create a revision history.xml, build the book in that language, ensure tha thte built revision historty adds the translated revision history to the english revision history.

Comment 18 Ruediger Landmann 2012-06-16 01:41:34 UTC

Verified in publican-3.0-0.fc17.t180.noarch

update_po adds a <lang>/Revision_History.xml file; building the book adds this file to the English Revision History. 

Updating the English Revision History and running update_po again correctly interleaves the translated and untranslated revision histories.

Comment 19 Frank Ch. Eigler 2013-03-11 15:38:16 UTC

Please note that this regresses publican's ability to render pre-existing documents, for example where the 'publish' facility and its putative naming requirements were never required.