|Summary:||RFE: respect rpm description layout|
|Product:||[Fedora] Fedora||Reporter:||Dwayne Bailey <dwayne>|
|Component:||yum||Assignee:||Seth Vidal <skvidal>|
|Status:||CLOSED UPSTREAM||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||ffesti, james.antill, katzj, pmatilai, tla|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-01-06 16:14:43 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Dwayne Bailey 2009-01-06 10:10:15 UTC
Description of problem: If a %description entry in an RPM file uses its own layout then yum will mangle the description rendering it unreadable. yum assumes descriptions are paragraphs of text that can be reflowed. Version-Release number of selected component (if applicable): 3.2.20-5 Steps to Reproduce: 1. rpm -qi translate-toolkit 2. yum info translate-toolkit 3. compare respective description sections Actual results: This will get garbled so I'll add an attachment later. rpm -qi translate toolkit # provides layout as specified in the .spec file yum info translate-toolkit # reflows text to make it unreadable Expected results: yum should respect the %description section so that lists and layout can be preserved. Additional info: For yum info the solution could be as simple as following the representation found in rpm i.e.: Description: Blah blah blah blah Instead of the current: Description: Blah : More blah There may be a need for such reflowing in applications that want to use the data e.g. GUI package installers such as those in PackageKit. But in this case it is probably better to either have some basic understanding of layout used or only reflow paragraphs that meet certain criteria. E.g. * Is a list * With items that can be reflowed If a paragraph does not start in column 1 it shouldn't be reflowed.
Comment 1 Dwayne Bailey 2009-01-06 10:17:20 UTC
Created attachment 328260 [details] Current output from rpm and yum and proposed changes Show current output from rpm and yum for the translate-toolkit package. Includes two examples of the suggested layout.
Comment 2 James Antill 2009-01-06 16:08:51 UTC
The 3.2.20-8 in rawhide, upstream and what will be in 3.2.21 gives the following output: Description: A set of tools for managing translation and software localization : via Gettext PO or XLIFF format files. : : Including: : * Convertors: convert from various formats to PO or XLIFF : * Formats: : * Core localization formats - XLIFF and Gettext PO : * Other localization formats - TMX, TBX, Qt Linguist (.ts), : Java .properties, Wordfast TM : * Compiled formats: Gettext MO, Qt .qm : * Other formats - text, HTML, CSV, INI, wiki (MediaWiki, : DokuWiki), iCal : * Specialised - OpenOffice.org GSI/SDF, PHP, : Mozilla (.dtd, .properties, etc) : * Tools: count, search, debug, segment and pretranslate : localization files. Extract terminology from localization : files. : * Checkers: validate translations with over 45 checks
Comment 3 James Antill 2009-01-06 16:14:43 UTC
Note that there are still a very few descriptions which we still can't flow properly (setools-devel is an example). So there is still some motivation for saying "just treat descriptions as an unflowable block of text", but I think this is very bad for the users. And the code in yum currently displays exactly what is in the description assuming the terminal is big enough. Saying that, PK is currently trying to completely redefine the description as some kind of Wiki text and can be changed at will ... so this may well change again, due to that succeeding, or due to the backlash from it.
Comment 4 Dwayne Bailey 2009-01-07 10:23:58 UTC
James -> thanks for the feedback and the new rendering is a relief. I agree that for users this is better and would rather suggest cleaning up the few broken %descriptions that can't be reflowed. For anyone reading this later: The markup used by PK is called Markdown, see: http://www.packagekit.org/pk-faq.html#markup They talk as if this actually works, but the current Fedora won't accept the markdown that I specified in my package.