From: Mark Hatle <mark.hatle@windriver.com>
To: <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 4/5] ncurses: Uncompress man pages
Date: Mon, 25 Jul 2011 14:14:16 -0500 [thread overview]
Message-ID: <4E2DC088.6070801@windriver.com> (raw)
In-Reply-To: <1311603225.30326.229.camel@phil-desktop>
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
next prev parent reply other threads:[~2011-07-25 19:18 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-25 13:47 [PATCH 0/5] Various multilib related fixes Richard Purdie
2011-07-25 13:47 ` [PATCH 1/5] multilib_header.bbclass: Add oe_multilib_header wrapper Richard Purdie
2011-07-25 13:54 ` Phil Blundell
2011-07-25 17:11 ` Mark Hatle
2011-07-25 20:06 ` Phil Blundell
2011-07-26 15:25 ` Mark Hatle
2011-07-25 14:35 ` Phil Blundell
2011-07-25 13:47 ` [PATCH 2/5] Fix recipe multilib header conflicts Richard Purdie
2011-07-25 14:08 ` Phil Blundell
2011-07-25 19:11 ` Mark Hatle
2011-07-25 13:47 ` [PATCH 3/5] eglibc: Update 2.13 to avoid multilib conflicts Richard Purdie
2011-07-25 13:59 ` Phil Blundell
2011-07-25 19:04 ` Mark Hatle
2011-07-25 20:04 ` Phil Blundell
2011-07-25 13:47 ` [PATCH 4/5] ncurses: Uncompress man pages Richard Purdie
2011-07-25 14:13 ` Phil Blundell
2011-07-25 19:14 ` Mark Hatle [this message]
2011-07-25 14:42 ` Enrico Scholz
2011-07-25 15:28 ` Phil Blundell
2011-07-25 13:47 ` [PATCH 5/5] package.bbclass: fixup_perms - symlink bug fix Richard Purdie
2011-07-25 14:05 ` Phil Blundell
2011-07-25 14:14 ` Enrico Scholz
2011-07-25 14:15 ` Phil Blundell
2011-07-25 19:08 ` Mark Hatle
2011-07-25 19:42 ` Phil Blundell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E2DC088.6070801@windriver.com \
--to=mark.hatle@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox