Patchwork [4/5] ncurses: Uncompress man pages

login
register
mail settings
Submitter Richard Purdie
Date July 25, 2011, 1:47 p.m.
Message ID <b7b6ab25887f5d5fcc541f44287942e1ccd150af.1311601422.git.richard.purdie@linuxfoundation.org>
Download mbox | patch
Permalink /patch/8435/
State New, archived
Headers show

Comments

Richard Purdie - July 25, 2011, 1:47 p.m.
From: Mark Hatle <mark.hatle@windriver.com>

If the man pages are compressed, then they cause file conflicts between
the 32-bit and 64-bit versions of the package.

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
---
 meta/recipes-core/ncurses/ncurses.inc |   15 +++++++++++++--
 1 files changed, 13 insertions(+), 2 deletions(-)
Phil Blundell - July 25, 2011, 2:13 p.m.
On Mon, 2011-07-25 at 14:47 +0100, Richard Purdie wrote:
> From: Mark Hatle <mark.hatle@windriver.com>
> 
> If the man pages are compressed, then they cause file conflicts between
> the 32-bit and 64-bit versions of the package.

I'm slightly bemused as to why it makes a difference (for this purpose)
whether the manpages are compressed or not, and I would have thought
that we would generally want to ship manpages as compressed for reasons
of disk-space efficiency.  Can you explain where exactly that conflict
comes from and why uncompressing the man pages resolves it?

> +inherit autotools binconfig multilib_header
>  
>[...]
>
> +	oe_multilib_header curses.h

This change isn't mentioned in either the short or long commit messages
and, as I mentioned in my previous email, it looks like it will cause
some complications with the LICENSE.

p.
Enrico Scholz - July 25, 2011, 2:42 p.m.
Richard Purdie
<richard.purdie-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
writes:

> If the man pages are compressed, then they cause file conflicts between
> the 32-bit and 64-bit versions of the package.

Patching the buildsystem to use 'gzip --no-name' might be a better
solution than uncompressing the man pages.

Alternatively, fixing/changing man page compression should be done in a
central class instead per recipe.


Enrico
Phil Blundell - July 25, 2011, 3:28 p.m.
On Mon, 2011-07-25 at 16:42 +0200, Enrico Scholz wrote:
> Richard Purdie
> <richard.purdie-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
> writes:
> 
> > If the man pages are compressed, then they cause file conflicts between
> > the 32-bit and 64-bit versions of the package.
> 
> Patching the buildsystem to use 'gzip --no-name' might be a better
> solution than uncompressing the man pages.
> 
> Alternatively, fixing/changing man page compression should be done in a
> central class instead per recipe.

I guess the other question that springs to mind is why the manpages are
in the same package as the binaries anyway.  Surely they ought to be in
the -doc package, which is presumably wordsize-agnostic, in which case
there oughtn't to be any conflict in the first place.

p.
Mark Hatle - July 25, 2011, 7:14 p.m.
On 7/25/11 9:13 AM, Phil Blundell wrote:
> On Mon, 2011-07-25 at 14:47 +0100, Richard Purdie wrote:
>> From: Mark Hatle <mark.hatle@windriver.com>
>>
>> If the man pages are compressed, then they cause file conflicts between
>> the 32-bit and 64-bit versions of the package.
> 
> I'm slightly bemused as to why it makes a difference (for this purpose)
> whether the manpages are compressed or not, and I would have thought
> that we would generally want to ship manpages as compressed for reasons
> of disk-space efficiency.  Can you explain where exactly that conflict
> comes from and why uncompressing the man pages resolves it?

If you don't use the gzip option "-n", both the name and timestamp of the
original file is encoded into the gzip archive.  This encoding makes the
compressed versions different from one build to the next.

Uncompressing resolves this since the file contents themselves are correct.

---

As for why they are being left uncompressed, when I could just re-gzip them
using the -n option..  My expectation is I'm going to be adding a new
package.bbclass step that searches for specific documentation files (man pages
specifically) and compresses them with the correct option(s) to avoid this
conflict.  So leaving them uncompressed made the most sense to me.

(Note, almost all of the other generated man pages on the system are already
uncompressed... that was the secondary reason for the change.)


>> +inherit autotools binconfig multilib_header
>>  
>> [...]
>>
>> +	oe_multilib_header curses.h
> 
> This change isn't mentioned in either the short or long commit messages
> and, as I mentioned in my previous email, it looks like it will cause
> some complications with the LICENSE.

Yes, this should have been with the previous patch dealing with header conflicts.

--Mark

> p.
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Patch

diff --git a/meta/recipes-core/ncurses/ncurses.inc b/meta/recipes-core/ncurses/ncurses.inc
index 1e139a3..f588022 100644
--- a/meta/recipes-core/ncurses/ncurses.inc
+++ b/meta/recipes-core/ncurses/ncurses.inc
@@ -6,9 +6,9 @@  LIC_FILES_CHKSUM = "file://ncurses/base/version.c;beginline=1;endline=27;md5=cbc
 SECTION = "libs"
 DEPENDS = "ncurses-native"
 DEPENDS_virtclass-native = ""
-INC_PR = "r0"
+INC_PR = "r1"
 
-inherit autotools binconfig
+inherit autotools binconfig multilib_header
 
 # Upstream has useful patches at times at ftp://invisible-island.net/ncurses/
 SRC_URI = "${GNU_MIRROR}/ncurses/ncurses-${PV}.tar.gz"
@@ -161,6 +161,17 @@  do_install() {
         f=${D}${libdir}/libtermcap.so
         echo '/* GNU ld script */' >$f
         echo 'INPUT(AS_NEEDED(-ltinfo))' >>$f
+
+	find ${D}${mandir} -type f -name "*.gz" | xargs gunzip
+	for each_link in `find ${D}${mandir} -type l -name "*.gz"` ; do
+		link_name=`echo $each_link | sed "s,\.gz$,,"`
+		target=`readlink -n $each_link | sed "s,\.gz$,,"`
+		echo "Changing $each_link to $link_name (-> $target)"
+		rm -f $each_link
+		ln -s $target $link_name
+	done
+
+	oe_multilib_header curses.h
 }
 
 python populate_packages_prepend () {