Patchwork [3/4] udev: Change hard coded /usr/lib to support multilib

login
register
mail settings
Submitter Dongxiao Xu
Date July 18, 2011, 6:13 a.m.
Message ID <c4ca6242b49eddc218fa3c0f58d172efc1601c84.1310969462.git.dongxiao.xu@intel.com>
Download mbox | patch
Permalink /patch/7753/
State New, archived
Headers show

Comments

Dongxiao Xu - July 18, 2011, 6:13 a.m.
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
---
 meta/recipes-core/udev/udev-164/makefile.patch |   16 ++++++++++++++++
 meta/recipes-core/udev/udev-new.inc            |    1 +
 meta/recipes-core/udev/udev_164.bb             |    2 +-
 3 files changed, 18 insertions(+), 1 deletions(-)
 create mode 100644 meta/recipes-core/udev/udev-164/makefile.patch
Koen Kooi - July 18, 2011, 7:08 a.m.
Op 18 jul 2011, om 08:13 heeft Dongxiao Xu het volgende geschreven:

> Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
> ---
> meta/recipes-core/udev/udev-164/makefile.patch |   16 ++++++++++++++++
> meta/recipes-core/udev/udev-new.inc            |    1 +
> meta/recipes-core/udev/udev_164.bb             |    2 +-
> 3 files changed, 18 insertions(+), 1 deletions(-)
> create mode 100644 meta/recipes-core/udev/udev-164/makefile.patch
> 
> diff --git a/meta/recipes-core/udev/udev-164/makefile.patch b/meta/recipes-core/udev/udev-164/makefile.patch
> new file mode 100644
> index 0000000..c46ff4b
> --- /dev/null
> +++ b/meta/recipes-core/udev/udev-164/makefile.patch
> @@ -0,0 +1,16 @@
> +Upstream-Status: Inappropriate [configuration]

Could you explain why it's inappropriate for upstream but why we do need it here?
Koen Kooi - July 18, 2011, 12:32 p.m.
Op 18 jul 2011, om 09:08 heeft Koen Kooi het volgende geschreven:

> 
> Op 18 jul 2011, om 08:13 heeft Dongxiao Xu het volgende geschreven:
> 
>> Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
>> ---
>> meta/recipes-core/udev/udev-164/makefile.patch |   16 ++++++++++++++++
>> meta/recipes-core/udev/udev-new.inc            |    1 +
>> meta/recipes-core/udev/udev_164.bb             |    2 +-
>> 3 files changed, 18 insertions(+), 1 deletions(-)
>> create mode 100644 meta/recipes-core/udev/udev-164/makefile.patch
>> 
>> diff --git a/meta/recipes-core/udev/udev-164/makefile.patch b/meta/recipes-core/udev/udev-164/makefile.patch
>> new file mode 100644
>> index 0000000..c46ff4b
>> --- /dev/null
>> +++ b/meta/recipes-core/udev/udev-164/makefile.patch
>> @@ -0,0 +1,16 @@
>> +Upstream-Status: Inappropriate [configuration]
> 
> Could you explain why it's inappropriate for upstream but why we do need it here?

I asked the udev maintainer:

14:25 < koen> kay: the udev Makefile.am has 'ln -sf $(libexecdir)/udev-acl $(DESTDIR)$(prefix)/lib/ConsoleKit/run-seat.d/udev-acl.ck', any reason for not using ${libdir} over ${prefix}/lib ?
14:29 < kay> koen: libdir is /usr/lib64 here, can't use that

So upstream is aware of multilib, but wants to put these scripts in a non-multilib dir. Since I don't have any experience with the fedora/opensuse way of multilib nor the new oe-core one, could you please explain why oe-core needs this patch, but fedora/opensuse don't?

regards,

Koen
Koen Kooi - July 18, 2011, 12:37 p.m.
Op 18 jul 2011, om 14:32 heeft Koen Kooi het volgende geschreven:

> 
> Op 18 jul 2011, om 09:08 heeft Koen Kooi het volgende geschreven:
> 
>> 
>> Op 18 jul 2011, om 08:13 heeft Dongxiao Xu het volgende geschreven:
>> 
>>> Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
>>> ---
>>> meta/recipes-core/udev/udev-164/makefile.patch |   16 ++++++++++++++++
>>> meta/recipes-core/udev/udev-new.inc            |    1 +
>>> meta/recipes-core/udev/udev_164.bb             |    2 +-
>>> 3 files changed, 18 insertions(+), 1 deletions(-)
>>> create mode 100644 meta/recipes-core/udev/udev-164/makefile.patch
>>> 
>>> diff --git a/meta/recipes-core/udev/udev-164/makefile.patch b/meta/recipes-core/udev/udev-164/makefile.patch
>>> new file mode 100644
>>> index 0000000..c46ff4b
>>> --- /dev/null
>>> +++ b/meta/recipes-core/udev/udev-164/makefile.patch
>>> @@ -0,0 +1,16 @@
>>> +Upstream-Status: Inappropriate [configuration]
>> 
>> Could you explain why it's inappropriate for upstream but why we do need it here?
> 
> I asked the udev maintainer:
> 
> 14:25 < koen> kay: the udev Makefile.am has 'ln -sf $(libexecdir)/udev-acl $(DESTDIR)$(prefix)/lib/ConsoleKit/run-seat.d/udev-acl.ck', any reason for not using ${libdir} over ${prefix}/lib ?
> 14:29 < kay> koen: libdir is /usr/lib64 here, can't use that
> 
> So upstream is aware of multilib, but wants to put these scripts in a non-multilib dir. Since I don't have any experience with the fedora/opensuse way of multilib nor the new oe-core one, could you please explain why oe-core needs this patch, but fedora/opensuse don't?


Some more:

14:33 < kay> koen: yeah, libdir can never be used for any "app private dir"
14:34 < kay> koen: /lib/<pkgname>/ /usr/lib/<pkgname>/ is app-priv-dir and never libdir
14:34 < kay> koen: but you should not use udev-acl anyway, i guess :)
14:34 < koen> that's another thing :)
14:34 < kay> koen: i disabled it by default now
14:34 < kay> all in sysyemd
14:34 < koen> the patch was for 164, I'm at 172 now without acl
14:35 < koen> we're adding multilib support to our buildsystem and we're having trouble judging when to use ${libdir} or ${prefix}/lib in some cases
14:35 < koen> I expected udev to be fairly sane by now, hence the question
14:35 < kay> koen: libdir only for .so, never anything else
Mark Hatle - July 18, 2011, 3:25 p.m.
On 7/18/11 7:32 AM, Koen Kooi wrote:
> 
> Op 18 jul 2011, om 09:08 heeft Koen Kooi het volgende geschreven:
> 
>>
>> Op 18 jul 2011, om 08:13 heeft Dongxiao Xu het volgende geschreven:
>>
>>> Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
>>> ---
>>> meta/recipes-core/udev/udev-164/makefile.patch |   16 ++++++++++++++++
>>> meta/recipes-core/udev/udev-new.inc            |    1 +
>>> meta/recipes-core/udev/udev_164.bb             |    2 +-
>>> 3 files changed, 18 insertions(+), 1 deletions(-)
>>> create mode 100644 meta/recipes-core/udev/udev-164/makefile.patch
>>>
>>> diff --git a/meta/recipes-core/udev/udev-164/makefile.patch b/meta/recipes-core/udev/udev-164/makefile.patch
>>> new file mode 100644
>>> index 0000000..c46ff4b
>>> --- /dev/null
>>> +++ b/meta/recipes-core/udev/udev-164/makefile.patch
>>> @@ -0,0 +1,16 @@
>>> +Upstream-Status: Inappropriate [configuration]
>>
>> Could you explain why it's inappropriate for upstream but why we do need it here?
> 
> I asked the udev maintainer:
> 
> 14:25 < koen> kay: the udev Makefile.am has 'ln -sf $(libexecdir)/udev-acl $(DESTDIR)$(prefix)/lib/ConsoleKit/run-seat.d/udev-acl.ck', any reason for not using ${libdir} over ${prefix}/lib ?
> 14:29 < kay> koen: libdir is /usr/lib64 here, can't use that
> 
> So upstream is aware of multilib, but wants to put these scripts in a non-multilib dir. Since I don't have any experience with the fedora/opensuse way of multilib nor the new oe-core one, could you please explain why oe-core needs this patch, but fedora/opensuse don't?

This is likely a problem with the multilib fix.  "libexecdir" is often /usr/lib
on many distribuions.. however as your other email mentioned.. setting it to
/usr/lib64 is a mistake.  It should be /usr/libexec or /usr/lib64.  All of the
associated multilib packages should work correctly and no conflicts introduced
with this package (file contents should be identical.)

It should be permissible for libexecdir to be changed in the configuration if
someone really wants it to be.  By default (in bitbake.conf) it is:

export libexecdir = "${exec_prefix}/libexec"

--Mark

> regards,
> 
> Koen
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Mark Hatle - July 18, 2011, 3:29 p.m.
Replying to myself.. sorry, I misunderstood the concern.. see below for a new
explanation..

On 7/18/11 10:25 AM, Mark Hatle wrote:
> On 7/18/11 7:32 AM, Koen Kooi wrote:
>>
>> Op 18 jul 2011, om 09:08 heeft Koen Kooi het volgende geschreven:
>>
>>>
>>> Op 18 jul 2011, om 08:13 heeft Dongxiao Xu het volgende geschreven:
>>>
>>>> Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
>>>> ---
>>>> meta/recipes-core/udev/udev-164/makefile.patch |   16 ++++++++++++++++
>>>> meta/recipes-core/udev/udev-new.inc            |    1 +
>>>> meta/recipes-core/udev/udev_164.bb             |    2 +-
>>>> 3 files changed, 18 insertions(+), 1 deletions(-)
>>>> create mode 100644 meta/recipes-core/udev/udev-164/makefile.patch
>>>>
>>>> diff --git a/meta/recipes-core/udev/udev-164/makefile.patch b/meta/recipes-core/udev/udev-164/makefile.patch
>>>> new file mode 100644
>>>> index 0000000..c46ff4b
>>>> --- /dev/null
>>>> +++ b/meta/recipes-core/udev/udev-164/makefile.patch
>>>> @@ -0,0 +1,16 @@
>>>> +Upstream-Status: Inappropriate [configuration]
>>>
>>> Could you explain why it's inappropriate for upstream but why we do need it here?
>>
>> I asked the udev maintainer:
>>
>> 14:25 < koen> kay: the udev Makefile.am has 'ln -sf $(libexecdir)/udev-acl $(DESTDIR)$(prefix)/lib/ConsoleKit/run-seat.d/udev-acl.ck', any reason for not using ${libdir} over ${prefix}/lib ?
>> 14:29 < kay> koen: libdir is /usr/lib64 here, can't use that
>>
>> So upstream is aware of multilib, but wants to put these scripts in a non-multilib dir. Since I don't have any experience with the fedora/opensuse way of multilib nor the new oe-core one, could you please explain why oe-core needs this patch, but fedora/opensuse don't?
> 
> This is likely a problem with the multilib fix.  "libexecdir" is often /usr/lib
> on many distribuions.. however as your other email mentioned.. setting it to
> /usr/lib64 is a mistake.  It should be /usr/libexec or /usr/lib64.  All of the
> associated multilib packages should work correctly and no conflicts introduced
> with this package (file contents should be identical.)
> 
> It should be permissible for libexecdir to be changed in the configuration if
> someone really wants it to be.  By default (in bitbake.conf) it is:
> 
> export libexecdir = "${exec_prefix}/libexec"

> +-	mkdir -p $(DESTDIR)$(prefix)/lib/ConsoleKit/run-seat.d
> +-	ln -sf $(libexecdir)/udev-acl $(DESTDIR)$(prefix)/lib/ConsoleKit/run-seat.d/udev-acl.ck
> ++	mkdir -p $(DESTDIR)$(libdir)/ConsoleKit/run-seat.d
> ++	ln -sf $(libexecdir)/udev-acl $(DESTDIR)$(libdir)/ConsoleKit/run-seat.d/udev-acl.ck

I see libexecdir CAN be changed.. so the above is already possible..

The part they had hard coded is "/usr/lib/ConsoleKit"...  There is only one
location in the system for ConsoleKit configuration files/scripts.. and that is
distro specific.  Assuming the oe based distributions use
$(PREFIX)/lib/ConsoleKit.. then the previous was correct.

The point being it doesn't matter if it's 32-bit, 64-bit or 24-bit...  only one
ConsoleKit per system should exist.  (There are potentially other files on the
system like this.  I know a recent RPM patch went in that separated /usr/lib/rpm
and /usr/lib64/rpm..  this is also a similar mistake, I just haven't had time to
get a patch out to revert that chunk.)

--Mark

> --Mark
> 
>> regards,
>>
>> Koen
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Dongxiao Xu - July 19, 2011, 12:30 a.m.
> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> Mark Hatle
> Sent: Monday, July 18, 2011 11:30 PM
> To: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 3/4] udev: Change hard coded /usr/lib to support
> multilib
> 
> Replying to myself.. sorry, I misunderstood the concern.. see below for a new
> explanation..
> 
> On 7/18/11 10:25 AM, Mark Hatle wrote:
> > On 7/18/11 7:32 AM, Koen Kooi wrote:
> >>
> >> Op 18 jul 2011, om 09:08 heeft Koen Kooi het volgende geschreven:
> >>
> >>>
> >>> Op 18 jul 2011, om 08:13 heeft Dongxiao Xu het volgende geschreven:
> >>>
> >>>> Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
> >>>> ---
> >>>> meta/recipes-core/udev/udev-164/makefile.patch |   16
> ++++++++++++++++
> >>>> meta/recipes-core/udev/udev-new.inc            |    1 +
> >>>> meta/recipes-core/udev/udev_164.bb             |    2 +-
> >>>> 3 files changed, 18 insertions(+), 1 deletions(-) create mode
> >>>> 100644 meta/recipes-core/udev/udev-164/makefile.patch
> >>>>
> >>>> diff --git a/meta/recipes-core/udev/udev-164/makefile.patch
> >>>> b/meta/recipes-core/udev/udev-164/makefile.patch
> >>>> new file mode 100644
> >>>> index 0000000..c46ff4b
> >>>> --- /dev/null
> >>>> +++ b/meta/recipes-core/udev/udev-164/makefile.patch
> >>>> @@ -0,0 +1,16 @@
> >>>> +Upstream-Status: Inappropriate [configuration]
> >>>
> >>> Could you explain why it's inappropriate for upstream but why we do need it
> here?
> >>
> >> I asked the udev maintainer:
> >>
> >> 14:25 < koen> kay: the udev Makefile.am has 'ln -sf $(libexecdir)/udev-acl
> $(DESTDIR)$(prefix)/lib/ConsoleKit/run-seat.d/udev-acl.ck', any reason for not
> using ${libdir} over ${prefix}/lib ?
> >> 14:29 < kay> koen: libdir is /usr/lib64 here, can't use that
> >>
> >> So upstream is aware of multilib, but wants to put these scripts in a
> non-multilib dir. Since I don't have any experience with the fedora/opensuse
> way of multilib nor the new oe-core one, could you please explain why oe-core
> needs this patch, but fedora/opensuse don't?
> >
> > This is likely a problem with the multilib fix.  "libexecdir" is often
> > /usr/lib on many distribuions.. however as your other email
> > mentioned.. setting it to
> > /usr/lib64 is a mistake.  It should be /usr/libexec or /usr/lib64.
> > All of the associated multilib packages should work correctly and no
> > conflicts introduced with this package (file contents should be
> > identical.)
> >
> > It should be permissible for libexecdir to be changed in the
> > configuration if someone really wants it to be.  By default (in bitbake.conf) it
> is:
> >
> > export libexecdir = "${exec_prefix}/libexec"
> 
> > +-	mkdir -p $(DESTDIR)$(prefix)/lib/ConsoleKit/run-seat.d
> > +-	ln -sf $(libexecdir)/udev-acl
> $(DESTDIR)$(prefix)/lib/ConsoleKit/run-seat.d/udev-acl.ck
> > ++	mkdir -p $(DESTDIR)$(libdir)/ConsoleKit/run-seat.d
> > ++	ln -sf $(libexecdir)/udev-acl
> > ++$(DESTDIR)$(libdir)/ConsoleKit/run-seat.d/udev-acl.ck
> 
> I see libexecdir CAN be changed.. so the above is already possible..
> 
> The part they had hard coded is "/usr/lib/ConsoleKit"...  There is only one
> location in the system for ConsoleKit configuration files/scripts.. and that is
> distro specific.  Assuming the oe based distributions use
> $(PREFIX)/lib/ConsoleKit.. then the previous was correct.
> 
> The point being it doesn't matter if it's 32-bit, 64-bit or 24-bit...  only one
> ConsoleKit per system should exist.  (There are potentially other files on the
> system like this.  I know a recent RPM patch went in that separated
> /usr/lib/rpm and /usr/lib64/rpm..  this is also a similar mistake, I just haven't
> had time to get a patch out to revert that chunk.)

So for multilib system, we have /usr/lib32 and /usr/lib64 to contain only *.so files, while there is still /usr/lib directory which contains other types of files, right?

Thanks,
Dongxiao

> 
> --Mark
> 
> > --Mark
> >
> >> regards,
> >>
> >> Koen
> >>
> >>
> >> _______________________________________________
> >> Openembedded-core mailing list
> >> Openembedded-core@lists.openembedded.org
> >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> >
> >
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Koen Kooi - July 19, 2011, 7:41 a.m.
Op 19 jul 2011, om 02:30 heeft Xu, Dongxiao het volgende geschreven:

>> -----Original Message-----
>> From: openembedded-core-bounces@lists.openembedded.org
>> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
>> Mark Hatle
>> Sent: Monday, July 18, 2011 11:30 PM
>> To: openembedded-core@lists.openembedded.org
>> Subject: Re: [OE-core] [PATCH 3/4] udev: Change hard coded /usr/lib to support
>> multilib
>> 
>> Replying to myself.. sorry, I misunderstood the concern.. see below for a new
>> explanation..
>> 
>> On 7/18/11 10:25 AM, Mark Hatle wrote:
>>> On 7/18/11 7:32 AM, Koen Kooi wrote:
>>>> 
>>>> Op 18 jul 2011, om 09:08 heeft Koen Kooi het volgende geschreven:
>>>> 
>>>>> 
>>>>> Op 18 jul 2011, om 08:13 heeft Dongxiao Xu het volgende geschreven:
>>>>> 
>>>>>> Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
>>>>>> ---
>>>>>> meta/recipes-core/udev/udev-164/makefile.patch |   16
>> ++++++++++++++++
>>>>>> meta/recipes-core/udev/udev-new.inc            |    1 +
>>>>>> meta/recipes-core/udev/udev_164.bb             |    2 +-
>>>>>> 3 files changed, 18 insertions(+), 1 deletions(-) create mode
>>>>>> 100644 meta/recipes-core/udev/udev-164/makefile.patch
>>>>>> 
>>>>>> diff --git a/meta/recipes-core/udev/udev-164/makefile.patch
>>>>>> b/meta/recipes-core/udev/udev-164/makefile.patch
>>>>>> new file mode 100644
>>>>>> index 0000000..c46ff4b
>>>>>> --- /dev/null
>>>>>> +++ b/meta/recipes-core/udev/udev-164/makefile.patch
>>>>>> @@ -0,0 +1,16 @@
>>>>>> +Upstream-Status: Inappropriate [configuration]
>>>>> 
>>>>> Could you explain why it's inappropriate for upstream but why we do need it
>> here?
>>>> 
>>>> I asked the udev maintainer:
>>>> 
>>>> 14:25 < koen> kay: the udev Makefile.am has 'ln -sf $(libexecdir)/udev-acl
>> $(DESTDIR)$(prefix)/lib/ConsoleKit/run-seat.d/udev-acl.ck', any reason for not
>> using ${libdir} over ${prefix}/lib ?
>>>> 14:29 < kay> koen: libdir is /usr/lib64 here, can't use that
>>>> 
>>>> So upstream is aware of multilib, but wants to put these scripts in a
>> non-multilib dir. Since I don't have any experience with the fedora/opensuse
>> way of multilib nor the new oe-core one, could you please explain why oe-core
>> needs this patch, but fedora/opensuse don't?
>>> 
>>> This is likely a problem with the multilib fix.  "libexecdir" is often
>>> /usr/lib on many distribuions.. however as your other email
>>> mentioned.. setting it to
>>> /usr/lib64 is a mistake.  It should be /usr/libexec or /usr/lib64.
>>> All of the associated multilib packages should work correctly and no
>>> conflicts introduced with this package (file contents should be
>>> identical.)
>>> 
>>> It should be permissible for libexecdir to be changed in the
>>> configuration if someone really wants it to be.  By default (in bitbake.conf) it
>> is:
>>> 
>>> export libexecdir = "${exec_prefix}/libexec"
>> 
>>> +-	mkdir -p $(DESTDIR)$(prefix)/lib/ConsoleKit/run-seat.d
>>> +-	ln -sf $(libexecdir)/udev-acl
>> $(DESTDIR)$(prefix)/lib/ConsoleKit/run-seat.d/udev-acl.ck
>>> ++	mkdir -p $(DESTDIR)$(libdir)/ConsoleKit/run-seat.d
>>> ++	ln -sf $(libexecdir)/udev-acl
>>> ++$(DESTDIR)$(libdir)/ConsoleKit/run-seat.d/udev-acl.ck
>> 
>> I see libexecdir CAN be changed.. so the above is already possible..
>> 
>> The part they had hard coded is "/usr/lib/ConsoleKit"...  There is only one
>> location in the system for ConsoleKit configuration files/scripts.. and that is
>> distro specific.  Assuming the oe based distributions use
>> $(PREFIX)/lib/ConsoleKit.. then the previous was correct.
>> 
>> The point being it doesn't matter if it's 32-bit, 64-bit or 24-bit...  only one
>> ConsoleKit per system should exist.  (There are potentially other files on the
>> system like this.  I know a recent RPM patch went in that separated
>> /usr/lib/rpm and /usr/lib64/rpm..  this is also a similar mistake, I just haven't
>> had time to get a patch out to revert that chunk.)
> 
> So for multilib system, we have /usr/lib32 and /usr/lib64 to contain only *.so files, while there is still /usr/lib directory which contains other types of files, right?

That's how I read it, but again, I'm no (multi)lib expert :)
Richard Purdie - July 19, 2011, 5:12 p.m.
On Tue, 2011-07-19 at 09:41 +0200, Koen Kooi wrote:
> Op 19 jul 2011, om 02:30 heeft Xu, Dongxiao het volgende geschreven:
> 
> >> -----Original Message-----
> >> From: openembedded-core-bounces@lists.openembedded.org
> >> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> >> Mark Hatle
> >> Sent: Monday, July 18, 2011 11:30 PM
> >> To: openembedded-core@lists.openembedded.org
> >> Subject: Re: [OE-core] [PATCH 3/4] udev: Change hard coded /usr/lib to support
> >> multilib
> >> 
> >> Replying to myself.. sorry, I misunderstood the concern.. see below for a new
> >> explanation..
> >> 
> >> On 7/18/11 10:25 AM, Mark Hatle wrote:
> >>> On 7/18/11 7:32 AM, Koen Kooi wrote:
> >>>> 
> >>>> Op 18 jul 2011, om 09:08 heeft Koen Kooi het volgende geschreven:
> >>>> 
> >>>>> 
> >>>>> Op 18 jul 2011, om 08:13 heeft Dongxiao Xu het volgende geschreven:
> >>>>> 
> >>>>>> Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
> >>>>>> ---
> >>>>>> meta/recipes-core/udev/udev-164/makefile.patch |   16
> >> ++++++++++++++++
> >>>>>> meta/recipes-core/udev/udev-new.inc            |    1 +
> >>>>>> meta/recipes-core/udev/udev_164.bb             |    2 +-
> >>>>>> 3 files changed, 18 insertions(+), 1 deletions(-) create mode
> >>>>>> 100644 meta/recipes-core/udev/udev-164/makefile.patch
> >>>>>> 
> >>>>>> diff --git a/meta/recipes-core/udev/udev-164/makefile.patch
> >>>>>> b/meta/recipes-core/udev/udev-164/makefile.patch
> >>>>>> new file mode 100644
> >>>>>> index 0000000..c46ff4b
> >>>>>> --- /dev/null
> >>>>>> +++ b/meta/recipes-core/udev/udev-164/makefile.patch
> >>>>>> @@ -0,0 +1,16 @@
> >>>>>> +Upstream-Status: Inappropriate [configuration]
> >>>>> 
> >>>>> Could you explain why it's inappropriate for upstream but why we do need it
> >> here?
> >>>> 
> >>>> I asked the udev maintainer:
> >>>> 
> >>>> 14:25 < koen> kay: the udev Makefile.am has 'ln -sf $(libexecdir)/udev-acl
> >> $(DESTDIR)$(prefix)/lib/ConsoleKit/run-seat.d/udev-acl.ck', any reason for not
> >> using ${libdir} over ${prefix}/lib ?
> >>>> 14:29 < kay> koen: libdir is /usr/lib64 here, can't use that
> >>>> 
> >>>> So upstream is aware of multilib, but wants to put these scripts in a
> >> non-multilib dir. Since I don't have any experience with the fedora/opensuse
> >> way of multilib nor the new oe-core one, could you please explain why oe-core
> >> needs this patch, but fedora/opensuse don't?
> >>> 
> >>> This is likely a problem with the multilib fix.  "libexecdir" is often
> >>> /usr/lib on many distribuions.. however as your other email
> >>> mentioned.. setting it to
> >>> /usr/lib64 is a mistake.  It should be /usr/libexec or /usr/lib64.
> >>> All of the associated multilib packages should work correctly and no
> >>> conflicts introduced with this package (file contents should be
> >>> identical.)
> >>> 
> >>> It should be permissible for libexecdir to be changed in the
> >>> configuration if someone really wants it to be.  By default (in bitbake.conf) it
> >> is:
> >>> 
> >>> export libexecdir = "${exec_prefix}/libexec"
> >> 
> >>> +-	mkdir -p $(DESTDIR)$(prefix)/lib/ConsoleKit/run-seat.d
> >>> +-	ln -sf $(libexecdir)/udev-acl
> >> $(DESTDIR)$(prefix)/lib/ConsoleKit/run-seat.d/udev-acl.ck
> >>> ++	mkdir -p $(DESTDIR)$(libdir)/ConsoleKit/run-seat.d
> >>> ++	ln -sf $(libexecdir)/udev-acl
> >>> ++$(DESTDIR)$(libdir)/ConsoleKit/run-seat.d/udev-acl.ck
> >> 
> >> I see libexecdir CAN be changed.. so the above is already possible..
> >> 
> >> The part they had hard coded is "/usr/lib/ConsoleKit"...  There is only one
> >> location in the system for ConsoleKit configuration files/scripts.. and that is
> >> distro specific.  Assuming the oe based distributions use
> >> $(PREFIX)/lib/ConsoleKit.. then the previous was correct.
> >> 
> >> The point being it doesn't matter if it's 32-bit, 64-bit or 24-bit...  only one
> >> ConsoleKit per system should exist.  (There are potentially other files on the
> >> system like this.  I know a recent RPM patch went in that separated
> >> /usr/lib/rpm and /usr/lib64/rpm..  this is also a similar mistake, I just haven't
> >> had time to get a patch out to revert that chunk.)
> > 
> > So for multilib system, we have /usr/lib32 and /usr/lib64 to contain
> only *.so files, while there is still /usr/lib directory which
> contains other types of files, right?
> 
> That's how I read it, but again, I'm no (multi)lib expert :)

Correct.

I would argue that architecture independent data files should really be
in $datadir and that configuration files should be in $sysconfdir.
$libdir should be used for architecture specific library files (likewise
libexecdir for executables). Not everyone is doing this sanely though. I
can understand the rpm issue from a history perspective but consolekit
doing it is plain wrong :/.

Architecture independent executables in the form of scripts are an
interesting case I guess.

Cheers,

Richard
Khem Raj - July 20, 2011, 5:08 p.m.
On 07/18/2011 05:30 PM, Xu, Dongxiao wrote:
>> -----Original Message-----
>> From: openembedded-core-bounces@lists.openembedded.org
>> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
>> Mark Hatle
>> Sent: Monday, July 18, 2011 11:30 PM
>> To: openembedded-core@lists.openembedded.org
>> Subject: Re: [OE-core] [PATCH 3/4] udev: Change hard coded /usr/lib to support
>> multilib
>>
>> Replying to myself.. sorry, I misunderstood the concern.. see below for a new
>> explanation..
>>
>> On 7/18/11 10:25 AM, Mark Hatle wrote:
>>> On 7/18/11 7:32 AM, Koen Kooi wrote:
>>>>
>>>> Op 18 jul 2011, om 09:08 heeft Koen Kooi het volgende geschreven:
>>>>
>>>>>
>>>>> Op 18 jul 2011, om 08:13 heeft Dongxiao Xu het volgende geschreven:
>>>>>
>>>>>> Signed-off-by: Dongxiao Xu<dongxiao.xu@intel.com>
>>>>>> ---
>>>>>> meta/recipes-core/udev/udev-164/makefile.patch |   16
>> ++++++++++++++++
>>>>>> meta/recipes-core/udev/udev-new.inc            |    1 +
>>>>>> meta/recipes-core/udev/udev_164.bb             |    2 +-
>>>>>> 3 files changed, 18 insertions(+), 1 deletions(-) create mode
>>>>>> 100644 meta/recipes-core/udev/udev-164/makefile.patch
>>>>>>
>>>>>> diff --git a/meta/recipes-core/udev/udev-164/makefile.patch
>>>>>> b/meta/recipes-core/udev/udev-164/makefile.patch
>>>>>> new file mode 100644
>>>>>> index 0000000..c46ff4b
>>>>>> --- /dev/null
>>>>>> +++ b/meta/recipes-core/udev/udev-164/makefile.patch
>>>>>> @@ -0,0 +1,16 @@
>>>>>> +Upstream-Status: Inappropriate [configuration]
>>>>>
>>>>> Could you explain why it's inappropriate for upstream but why we do need it
>> here?
>>>>
>>>> I asked the udev maintainer:
>>>>
>>>> 14:25<  koen>  kay: the udev Makefile.am has 'ln -sf $(libexecdir)/udev-acl
>> $(DESTDIR)$(prefix)/lib/ConsoleKit/run-seat.d/udev-acl.ck', any reason for not
>> using ${libdir} over ${prefix}/lib ?
>>>> 14:29<  kay>  koen: libdir is /usr/lib64 here, can't use that
>>>>
>>>> So upstream is aware of multilib, but wants to put these scripts in a
>> non-multilib dir. Since I don't have any experience with the fedora/opensuse
>> way of multilib nor the new oe-core one, could you please explain why oe-core
>> needs this patch, but fedora/opensuse don't?
>>>
>>> This is likely a problem with the multilib fix.  "libexecdir" is often
>>> /usr/lib on many distribuions.. however as your other email
>>> mentioned.. setting it to
>>> /usr/lib64 is a mistake.  It should be /usr/libexec or /usr/lib64.
>>> All of the associated multilib packages should work correctly and no
>>> conflicts introduced with this package (file contents should be
>>> identical.)
>>>
>>> It should be permissible for libexecdir to be changed in the
>>> configuration if someone really wants it to be.  By default (in bitbake.conf) it
>> is:
>>>
>>> export libexecdir = "${exec_prefix}/libexec"
>>
>>> +-	mkdir -p $(DESTDIR)$(prefix)/lib/ConsoleKit/run-seat.d
>>> +-	ln -sf $(libexecdir)/udev-acl
>> $(DESTDIR)$(prefix)/lib/ConsoleKit/run-seat.d/udev-acl.ck
>>> ++	mkdir -p $(DESTDIR)$(libdir)/ConsoleKit/run-seat.d
>>> ++	ln -sf $(libexecdir)/udev-acl
>>> ++$(DESTDIR)$(libdir)/ConsoleKit/run-seat.d/udev-acl.ck
>>
>> I see libexecdir CAN be changed.. so the above is already possible..
>>
>> The part they had hard coded is "/usr/lib/ConsoleKit"...  There is only one
>> location in the system for ConsoleKit configuration files/scripts.. and that is
>> distro specific.  Assuming the oe based distributions use
>> $(PREFIX)/lib/ConsoleKit.. then the previous was correct.
>>
>> The point being it doesn't matter if it's 32-bit, 64-bit or 24-bit...  only one
>> ConsoleKit per system should exist.  (There are potentially other files on the
>> system like this.  I know a recent RPM patch went in that separated
>> /usr/lib/rpm and /usr/lib64/rpm..  this is also a similar mistake, I just haven't
>> had time to get a patch out to revert that chunk.)
>
> So for multilib system, we have /usr/lib32 and /usr/lib64 to contain only *.so files, while there is still /usr/lib directory which contains other types of files, right?

in ideal world /usr/lib could just be a symlink to default multilib

Patch

diff --git a/meta/recipes-core/udev/udev-164/makefile.patch b/meta/recipes-core/udev/udev-164/makefile.patch
new file mode 100644
index 0000000..c46ff4b
--- /dev/null
+++ b/meta/recipes-core/udev/udev-164/makefile.patch
@@ -0,0 +1,16 @@ 
+Upstream-Status: Inappropriate [configuration]
+
+diff -ruN udev-164-orig/Makefile.am udev-164/Makefile.am
+--- udev-164-orig/Makefile.am	2011-07-11 16:10:26.000000000 +0800
++++ udev-164/Makefile.am	2011-07-11 16:11:14.000000000 +0800
+@@ -468,8 +468,8 @@
+ libexec_PROGRAMS += extras/udev-acl/udev-acl
+ 
+ udevacl-install-hook:
+-	mkdir -p $(DESTDIR)$(prefix)/lib/ConsoleKit/run-seat.d
+-	ln -sf $(libexecdir)/udev-acl $(DESTDIR)$(prefix)/lib/ConsoleKit/run-seat.d/udev-acl.ck
++	mkdir -p $(DESTDIR)$(libdir)/ConsoleKit/run-seat.d
++	ln -sf $(libexecdir)/udev-acl $(DESTDIR)$(libdir)/ConsoleKit/run-seat.d/udev-acl.ck
+ 
+ INSTALL_EXEC_HOOKS += udevacl-install-hook
+ 
diff --git a/meta/recipes-core/udev/udev-new.inc b/meta/recipes-core/udev/udev-new.inc
index 4c4451f..b482a5a 100644
--- a/meta/recipes-core/udev/udev-new.inc
+++ b/meta/recipes-core/udev/udev-new.inc
@@ -16,6 +16,7 @@  RRECOMMENDS_${PN} += "udev-extraconf udev-cache usbutils-ids pciutils-ids"
 RDEPENDS_libudev = "${PN} (= ${EXTENDPKGV})"
 
 SRC_URI = "${KERNELORG_MIRROR}/linux/utils/kernel/hotplug/udev-${PV}.tar.gz \
+           file://makefile.patch \
            file://run.rules \
            file://udev.rules \
            file://devfs-udev.rules \
diff --git a/meta/recipes-core/udev/udev_164.bb b/meta/recipes-core/udev/udev_164.bb
index 567e62e..518d37a 100644
--- a/meta/recipes-core/udev/udev_164.bb
+++ b/meta/recipes-core/udev/udev_164.bb
@@ -1,6 +1,6 @@ 
 include udev-new.inc
 
-PR = "r3"
+PR = "r4"
 
 SRC_URI[md5sum] = "fddac2d54761ea34865af9467377ca9f"
 SRC_URI[sha256sum] = "c12e66280b5e1465f6587a8cfa47d7405c4caa7e52ce5dd13478d04f6ec05e5c"