Patchwork [0/2] Move systemd binaries to /sbin/systemd

login
register
mail settings
Submitter Ross Burton
Date April 11, 2013, 4:28 p.m.
Message ID <cover.1365697555.git.ross.burton@intel.com>
Download mbox
Permalink /patch/47977/
State New
Headers show

Pull-request

git://git.yoctoproject.org/poky-contrib ross/systemd

Comments

Ross Burton - April 11, 2013, 4:28 p.m.
Hi,

Following the example set by udev, move the binaries to /sbin/systemd and
hardcode less paths in general.  Tested on atom-pc with a .hddimg so the live
boot/initrd paths were tested.

Ross

The following changes since commit 2ef72c3174c8c111678ac7e3cf3d866eaf2c8d77:

  wayland: add necessary dependencies to fix build error (2013-04-11 16:41:13 +0100)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib ross/systemd

for you to fetch changes up to 0154334c32234d70dc064fb7dac6b499ca91cf3a:

  initrdscripts: look for new systemd-udevd location (2013-04-11 17:18:19 +0100)

----------------------------------------------------------------
Ross Burton (2):
      systemd: move the binaries to /sbin/systemd
      initrdscripts: look for new systemd-udevd location

 meta/recipes-core/initrdscripts/files/init-live.sh |    2 +-
 .../initrdscripts/initramfs-framework/udev         |    2 +-
 meta/recipes-core/systemd/systemd/init             |   14 +++---
 meta/recipes-core/systemd/systemd_199.bb           |   46 +++++++-------------
 4 files changed, 25 insertions(+), 39 deletions(-)
Enrico Scholz - April 15, 2013, 11 a.m.
Ross Burton <ross.burton-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
writes:

> Following the example set by udev, move the binaries to /sbin/systemd
> and hardcode less paths in general.  Tested on atom-pc with a .hddimg
> so the live boot/initrd paths were tested.

At least the moving of udev breaks a lot of local recipes here which
install e.g. local rules or keymaps in /lib/udev.  This is a silent break
which is detected at device runtime only.  The global 'bitbake.conf' has
not been updated for the new paths neither.


There should be:

1. added some QA checks which detect this broken packaging

2. added some global variables (e.g. 'udev_basedir') which can be used
   in the rules.



Enrico
Koen Kooi - April 15, 2013, 11:21 a.m.
Op 15 apr. 2013, om 13:00 heeft Enrico Scholz <enrico.scholz@sigma-chemnitz.de> het volgende geschreven:

> Ross Burton <ross.burton-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> writes:
> 
>> Following the example set by udev, move the binaries to /sbin/systemd
>> and hardcode less paths in general.  Tested on atom-pc with a .hddimg
>> so the live boot/initrd paths were tested.
> 
> At least the moving of udev breaks a lot of local recipes here which
> install e.g. local rules or keymaps in /lib/udev.  This is a silent break
> which is detected at device runtime only.  The global 'bitbake.conf' has
> not been updated for the new paths neither.
> 
> 
> There should be:
> 
> 1. added some QA checks which detect this broken packaging
> 
> 2. added some global variables (e.g. 'udev_basedir') which can be used
>   in the rules.

These patches can get NAK'd all you want, but they will go in. I still say: NAK, this is a bad, bad idea. It diverges from upstream and introduces silent breakage as you point out due to that.
Richard Purdie - April 15, 2013, 3:15 p.m.
On Mon, 2013-04-15 at 13:21 +0200, Koen Kooi wrote:
> Op 15 apr. 2013, om 13:00 heeft Enrico Scholz <enrico.scholz@sigma-chemnitz.de> het volgende geschreven:
> 
> > Ross Burton <ross.burton-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> > writes:
> > 
> >> Following the example set by udev, move the binaries to /sbin/systemd
> >> and hardcode less paths in general.  Tested on atom-pc with a .hddimg
> >> so the live boot/initrd paths were tested.
> > 
> > At least the moving of udev breaks a lot of local recipes here which
> > install e.g. local rules or keymaps in /lib/udev.  This is a silent break
> > which is detected at device runtime only.  The global 'bitbake.conf' has
> > not been updated for the new paths neither.
> > 
> > 
> > There should be:
> > 
> > 1. added some QA checks which detect this broken packaging
> > 
> > 2. added some global variables (e.g. 'udev_basedir') which can be used
> >   in the rules.
> 
> These patches can get NAK'd all you want, but they will go in. I still
> say: NAK, this is a bad, bad idea. It diverges from upstream and
> introduces silent breakage as you point out due to that.

In the 1.5 timeframe I want to look at this again and see how we can
better solve it as it may be we can do something to the multilib code to
avoid the issues. We ran out of runway with this for 1.4 :(.

Cheers,

Richard
Enrico Scholz - April 15, 2013, 3:58 p.m.
Richard Purdie <richard.purdie@linuxfoundation.org> writes:

>> >> Following the example set by udev, move the binaries to /sbin/systemd
>> >> and hardcode less paths in general.  Tested on atom-pc with a .hddimg
>> >> so the live boot/initrd paths were tested.
>> > 
>> > At least the moving of udev breaks a lot of local recipes here which
>> > install e.g. local rules or keymaps in /lib/udev.  This is a silent break
>> > which is detected at device runtime only.  The global 'bitbake.conf' has
>> > not been updated for the new paths neither.
>> > 
>> > 
>> > There should be:
>> > 
>> > 1. added some QA checks which detect this broken packaging
>> > 
>> > 2. added some global variables (e.g. 'udev_basedir') which can be used
>> >   in the rules.
>> 
>> These patches can get NAK'd all you want, but they will go in. I still
>> say: NAK, this is a bad, bad idea. It diverges from upstream and
>> introduces silent breakage as you point out due to that.
>
> In the 1.5 timeframe I want to look at this again and see how we can
> better solve it as it may be we can do something to the multilib code to
> avoid the issues. We ran out of runway with this for 1.4 :(.

Does this mean, this last-minute and invasive patch gets reverted (-->
it is already in oe). Or, that it stays and we have to live in 1.4 with
bad surprises[1] because an undefined number of packages[2] uses still
the upstream defaults?



Enrico

Footnotes: 
[1]  udev rules, keymaps and firmware at the wrong location

[2]  surprisingly, 'systemd' itself where this change has been applied
     still refers to /lib/udev/rules.d