* Upcoming rpms: i2c headers under /usr/include/i2c
2005-05-19 6:25 Upcoming rpms: i2c headers under /usr/include/i2c Axel Thimm
@ 2005-05-19 6:25 ` Jean Delvare
2005-05-19 6:25 ` Axel Thimm
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Jean Delvare @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
Hi Axel,
> packaging up i2c and lm_sensors I had to move the i2c headers
> somehwere else than under /usr/include (and /usr/local is "forbidden"
> for packages).
>
> Due to lack of any further creative thinking I just added another i2c
> directory hierarchy, so the rpms will offer
>
> /usr/include/i2c/linux/i2c -> 2.9.0
>
> and glibc-kernheaders will contain the old i2c headers under
>
> /usr/include/linux/i2c
>
> Building lm_sensors against that is not an issue, as the location of
> the headers can be specified. I wonder if there are other projects
> depending on the i2c headers, that would have to be diverted to the
> new location when packaged.
I have no idea whether other packages need it. If there are, these would
probably be third-party multimedia drivers.
Please note that almost all headers included in lm_sensors are not
supposed to be "exported" to /usr/include (or whatever) since they
really are headers for kernel space, not user space. I have removed all
header exports from i2c 2.9.0, and lm_sensors will probably go the same
path soon. The ony file which is really needed from userspace is
i2c-dev.h (the one which is in lm_sensors, but which should probably be
moved back to i2c at some later time).
> I also packaged the headers into i2c-kernheaders instead of
> ivtv-devel, as this seems to be the current practice at Red Hat
> (headers for conventional libs get into foo-devel, headers for kernel
> modules get into foo-kernheaders).
I assume you mean i2c-devel, not ivtv-devel?
--
Jean Delvare
http://khali.linux-fr.org/
^ permalink raw reply [flat|nested] 7+ messages in thread* Upcoming rpms: i2c headers under /usr/include/i2c
2005-05-19 6:25 Upcoming rpms: i2c headers under /usr/include/i2c Axel Thimm
2005-05-19 6:25 ` Jean Delvare
@ 2005-05-19 6:25 ` Axel Thimm
2005-05-19 6:25 ` Axel Thimm
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Axel Thimm @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
Hi,
On Sat, Jan 01, 2005 at 05:06:00PM +0100, Jean Delvare wrote:
> > packaging up i2c and lm_sensors I had to move the i2c headers
> > somehwere else than under /usr/include (and /usr/local is "forbidden"
> > for packages).
> >
> > Due to lack of any further creative thinking I just added another i2c
> > directory hierarchy, so the rpms will offer
> >
> > /usr/include/i2c/linux/i2c -> 2.9.0
> >
> > and glibc-kernheaders will contain the old i2c headers under
> >
> > /usr/include/linux/i2c
> >
> > Building lm_sensors against that is not an issue, as the location of
> > the headers can be specified. I wonder if there are other projects
> > depending on the i2c headers, that would have to be diverted to the
> > new location when packaged.
>
> I have no idea whether other packages need it. If there are, these would
> probably be third-party multimedia drivers.
>
> Please note that almost all headers included in lm_sensors are not
> supposed to be "exported" to /usr/include (or whatever) since they
> really are headers for kernel space, not user space.
Where should kernel space headers for building depending kernel
modules go? You need the "i2c-kernheaders" at least for building the
lm_sensors kernel modules. Perhaps /usr/include/linux is for userland
interfacing the kernel, but then there is no FHS place for
kernel-kernel headers (they are assumed to be hiding in the kernel
source only). Perhaps per kernel /lib/modules/.../{source,build}
locations would have been more appropriate.
> I have removed all header exports from i2c 2.9.0, and lm_sensors
> will probably go the same path soon. The ony file which is really
> needed from userspace is i2c-dev.h (the one which is in lm_sensors,
> but which should probably be moved back to i2c at some later time).
>
> > I also packaged the headers into i2c-kernheaders instead of
> > ivtv-devel, as this seems to be the current practice at Red Hat
> > (headers for conventional libs get into foo-devel, headers for kernel
> > modules get into foo-kernheaders).
>
> I assume you mean i2c-devel, not ivtv-devel?
Yes, sorry, a typo. :)
--
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20050101/f3bb3ac6/attachment.bin
^ permalink raw reply [flat|nested] 7+ messages in thread* Upcoming rpms: i2c headers under /usr/include/i2c
2005-05-19 6:25 Upcoming rpms: i2c headers under /usr/include/i2c Axel Thimm
2005-05-19 6:25 ` Jean Delvare
2005-05-19 6:25 ` Axel Thimm
@ 2005-05-19 6:25 ` Axel Thimm
2005-05-19 6:25 ` Jean Delvare
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Axel Thimm @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
On Mon, Jan 03, 2005 at 01:40:07PM +0100, Jean Delvare wrote:
> > > I have no idea where the correct location would be, so anything you
> > > come with is fine with me.
> >
> > Perhaps indeed /usr/include/i2c/linux/i2c?
> >
> > And I2C_HEADERS need to point (and default) to /usr/include/i2c, while
> >
> > #include <linux/i2c/....>
> >
> > picks the header either from a proper Linux kernel tree or from
> > I2C_HEADERS.
>
> Since the includes actually are <linux/...>, not <linux/i2c/...>, that
> would be /use/include/i2c/linux. It is obviously important to have the
> same include "tree" (even if it has just a depth of 1) in /usr/include
> (or wherever it'll end) than we have in the Linux kernel source tree.
Yes, I mistyped the above. Actually for the rpms I did
mkdir -p %{buildroot}%{_includedir}/i2c/linux
cp -a kernel/*.h %{buildroot}%{_includedir}/i2c/linux
where buildroot is the "DESTDIR" for rpm builds and _includedir is the
macro pointing to /usr/include.
So I'm using /usr(/local)/include/i2c/linux for the headers and the
extra i2c slipped only in the mail above :)
BTW I didn't make any special announcements here, but the i2c and
lm_sensors rpm for RH7.3 til FC3 are uploaded at ATrpms. :=)
--
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20050103/ede87b4b/attachment.bin
^ permalink raw reply [flat|nested] 7+ messages in thread* Upcoming rpms: i2c headers under /usr/include/i2c
2005-05-19 6:25 Upcoming rpms: i2c headers under /usr/include/i2c Axel Thimm
` (2 preceding siblings ...)
2005-05-19 6:25 ` Axel Thimm
@ 2005-05-19 6:25 ` Jean Delvare
2005-05-19 6:25 ` Axel Thimm
2005-05-19 6:25 ` Jean Delvare
5 siblings, 0 replies; 7+ messages in thread
From: Jean Delvare @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
> > I have no idea where the correct location would be, so anything you
> > come with is fine with me.
>
> Perhaps indeed /usr/include/i2c/linux/i2c?
>
> And I2C_HEADERS need to point (and default) to /usr/include/i2c, while
>
> #include <linux/i2c/....>
>
> picks the header either from a proper Linux kernel tree or from
> I2C_HEADERS.
Since the includes actually are <linux/...>, not <linux/i2c/...>, that
would be /use/include/i2c/linux. It is obviously important to have the
same include "tree" (even if it has just a depth of 1) in /usr/include
(or wherever it'll end) than we have in the Linux kernel source tree.
> If not /usr/include/i2c then perhaps /usr/local/include/i2c to be in
> sync with the other /usr/local defaults.
i2c and lm_sensors default to /usr/local for everything they install
(except for the libsensors configuration file) and I don't think we will
change this now. Thus I would go for /usr/local/include/i2c, but of
course you could do /usr/include/i2c on your RPM packages if it fits the
Red Hat/Fedora policy better.
Anyway, before going there, we'd better fix i2c 2.9.0 so that if does
install the header files at the old location again, so that people can
compile lm_sensors.
--
Jean Delvare
http://khali.linux-fr.org/
^ permalink raw reply [flat|nested] 7+ messages in thread* Upcoming rpms: i2c headers under /usr/include/i2c
2005-05-19 6:25 Upcoming rpms: i2c headers under /usr/include/i2c Axel Thimm
` (3 preceding siblings ...)
2005-05-19 6:25 ` Jean Delvare
@ 2005-05-19 6:25 ` Axel Thimm
2005-05-19 6:25 ` Jean Delvare
5 siblings, 0 replies; 7+ messages in thread
From: Axel Thimm @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
On Sun, Jan 02, 2005 at 11:26:13AM +0100, Jean Delvare wrote:
> > Where should kernel space headers for building depending kernel
> > modules go? You need the "i2c-kernheaders" at least for building
> > the lm_sensors kernel modules.
> > Perhaps /usr/include/linux is for userland
> > interfacing the kernel, but then there is no FHS place for
> > kernel-kernel headers (they are assumed to be hiding in the kernel
> > source only). Perhaps per kernel /lib/modules/.../{source,build}
> > locations would have been more appropriate.
>
> I have no idea where the correct location would be, so anything you come
> with is fine with me.
Perhaps indeed /usr/include/i2c/linux/i2c?
And I2C_HEADERS need to point (and default) to /usr/include/i2c, while
#include <linux/i2c/....>
picks the header either from a proper Linux kernel tree or from
I2C_HEADERS.
If not /usr/include/i2c then perhaps /usr/local/include/i2c to be in
sync with the other /usr/local defaults.
--
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20050103/aecfac20/attachment.bin
^ permalink raw reply [flat|nested] 7+ messages in thread* Upcoming rpms: i2c headers under /usr/include/i2c
2005-05-19 6:25 Upcoming rpms: i2c headers under /usr/include/i2c Axel Thimm
` (4 preceding siblings ...)
2005-05-19 6:25 ` Axel Thimm
@ 2005-05-19 6:25 ` Jean Delvare
5 siblings, 0 replies; 7+ messages in thread
From: Jean Delvare @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
> > Please note that almost all headers included in lm_sensors are not
> > supposed to be "exported" to /usr/include (or whatever) since they
> > really are headers for kernel space, not user space.
>
> Where should kernel space headers for building depending kernel
> modules go? You need the "i2c-kernheaders" at least for building the
> lm_sensors kernel modules.
Damn. I completely missed that. At the moment I removed the headers
export from i2c, I was mostly thinking of the patch-the-kernel
installation option, which goes fine without exporting the headers, of
course. I also remembered that "user-space should not include
kernel-space headers", and I completely forgot that lm_sensors actually
needs these ones. I had no problem when testing because I had "old"
headers remaining from before the change, which were recent enough to
work OK. Unfortunately, it won't work for other people out there because
1* they might not have any "old" version if they install i2c for the
first time and 2* the important compatibility changes I made make the
2.8.x versions useless anyway.
Ticket #1857 shows the problem. I expect many similar complaints in the
next few days and week. I apologize for being such a moron and breaking
i2c a few weeks before the 2.9.0 release without proper testing of the
change I made.
We of course need to revert the change in CVS but it won't fix the
released 2.9.0 package. Options we have now:
1* Silently re-release 2.9.0 with the change.
2* Release 2.9.1 ASAP with the change.
3* Provide a patch on the download page.
Option 3 is probably the most simple... Opinion anyone?
> Perhaps /usr/include/linux is for userland
> interfacing the kernel, but then there is no FHS place for
> kernel-kernel headers (they are assumed to be hiding in the kernel
> source only). Perhaps per kernel /lib/modules/.../{source,build}
> locations would have been more appropriate.
I have no idea where the correct location would be, so anything you come
with is fine with me.
Very sorry again,
--
Jean Delvare
http://khali.linux-fr.org/
^ permalink raw reply [flat|nested] 7+ messages in thread