From: Koen Kooi <k.kooi@student.utwente.nl>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [oe-commits] Philip Balister : i2c-tools : Stage i2c-dev.h header as i2c-dev-user.h.
Date: Wed, 15 Dec 2010 09:16:04 +0100 [thread overview]
Message-ID: <ie9tg4$9t0$1@dough.gmane.org> (raw)
In-Reply-To: <20101214133729.GE6662@jama>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 14-12-10 14:37, Martin Jansa wrote:
> On Tue, Dec 14, 2010 at 08:30:46AM -0500, Philip Balister wrote:
>> On 12/14/2010 07:06 AM, Dr. Michael Lauer wrote:
>>> Am 10.12.2010 um 15:36 schrieb git version control:
>>>
>>>> Module: openembedded.git
>>>> Branch: org.openembedded.dev
>>>> Commit: 48e6a063370a38a35f31a28efd8f6ce6ebf00840
>>>> URL: http://gitweb.openembedded.net/?p=openembedded.git&a=commit;h=48e6a063370a38a35f31a28efd8f6ce6ebf00840
>>>>
>>>> Author: Philip Balister<philip@balister.org>
>>>> Date: Fri Dec 10 09:31:01 2010 -0500
>>>>
>>>> i2c-tools : Stage i2c-dev.h header as i2c-dev-user.h.
>>>>
>>>> Thanks to John Faith for suggesting this approach on the ML. The problem is
>>>> i2c-tools overwrites the header staged by the kernel. This breaks programs
>>>> that depend on the kernel header.
>>>
>>> I don't think this a good solution. Now all programs break which expect
>>> this very i2c-dev.h as being staged by i2c-tools. Interestingly, the
>>> desktop distros don't bother about staging it differently, so why
>>> can't we do the same? Besides, the i2c-dev.h as staged by i2c-tools
>>> is supposed to be a superset. If it isn't we should complain with the
>>> i2c-tools developers.
>>>
>>> What can we do in the meantime?
>>
>> Can we get a survey of how other distros handle the situation?
>
> Gentoo
> i2c-tools-3.0.[012] (all versions)
> src_install() {
> emake install prefix="${D}"/usr || die
> rm -rf "${D}"/usr/include # part of linux-headers
> ...
> }
>
> so it's not part of i2c-tools package (gentoo doesn't have concept of
> -dev packages as it's always usefull to have all -dev stuff on source
> based distribution).
What are other distributions based on? Pixie dust?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
iD8DBQFNCHlEMkyGM64RGpERAjhiAJ0ZSOL1sTzWT1vz9B5BR4bW4wqwqwCgj2Zh
BHqHQqhZva9Zh3MekrMNk7I=
=632I
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2010-12-15 8:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <E1PR45K-0000jK-SU@melo.openembedded.org>
2010-12-14 12:06 ` [oe-commits] Philip Balister : i2c-tools : Stage i2c-dev.h header as i2c-dev-user.h Dr. Michael Lauer
2010-12-14 13:30 ` Philip Balister
2010-12-14 13:37 ` Martin Jansa
2010-12-15 8:16 ` Koen Kooi [this message]
2010-12-15 8:29 ` Martin Jansa
2010-12-15 12:45 ` Philip Balister
2010-12-15 13:15 ` Andreas Oberritter
2010-12-16 6:34 ` Khem Raj
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='ie9tg4$9t0$1@dough.gmane.org' \
--to=k.kooi@student.utwente.nl \
--cc=openembedded-devel@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