[oe] update-alternatives broken badly (by me :()

[Martin Jansa]

Hi,

Still no review/ACK :(.

I'll try to explain it better to show how bad it can be and even make
review easier.

We have target where sysvinit as init is crucial for successful boot (ie
SHR on freerunner) and u-a-cworth is installed on image, because
task-boot RDEPENDs on update-alternatives.

Let's start with image built after 2009-12-08.
u-a-opkg is used for in do_rootfs, but u-a-cworth is installed in image
too and is used by default.

T1) after flashing
  ipkg/alternatives/init        opkg/alternatives/init
    doesnt-exist                  /sbin/init
                                  /sbin/init.sysvinit 60
                                 ../bin/busybox 50
  =>sysvinit is used, everything is fine

good scenario:
T2a) sysvinit is upgraded first
  ipkg/alternatives/init        opkg/alternatives/init
    /sbin/init                    /sbin/init
    /sbin/init.sysvinit 60        /sbin/init.sysvinit 60
                                  ../bin/busybox 50
  =>sysvinit is used, everything is fine
  - newer file works but is incomplete

T3a) busybox is upgraded
  ipkg/alternatives/init        opkg/alternatives/init
    /sbin/init                    /sbin/init
    /sbin/init.sysvinit 60        /sbin/init.sysvinit 60
    ../bin/busybox 50             ../bin/busybox 50
  =>sysvinit is used, everything is fine
  - newer file works and is the same as opkg

bad scenario
T2b) busybox is upgrade first
  ipkg/alternatives/init        opkg/alternatives/init
    /sbin/init                    /sbin/init
    ../bin/busybox 50             /sbin/init.sysvinit 60
                                  ../bin/busybox 50
  =>busybox is used, device won't boot anymore
  - newer file is from cworth but is worse

T3b) sysvinit is upgraded
  ipkg/alternatives/init        opkg/alternatives/init
    /sbin/init                    /sbin/init
    /sbin/init.sysvinit 60        /sbin/init.sysvinit 60
  ../bin/busybox 50             ../bin/busybox 50
  
  =>sysvinit is used again, everything is fine
  - newer file works and is the same again

If we merge ipkg/alternatives and opkg/alternatives before T2b) there
will be no problem.

If we merge it after T2b) and then force busybox upgrade then we will
fix broken image too (as busybox is using probably the most u-a links
and has lowest priority). So busybox PR bump is good idea AFTER merging
u-a alternatives.

Worst scenario (where merger fails):
Tfsck) After T3a) or T3b) user intentionally remove sysvint package 
  (ie because he can boot even with busybox)
  ipkg/alternatives/init        opkg/alternatives/init
    /sbin/init                    /sbin/init
    ../bin/busybox 50             /sbin/init.sysvinit 60
                                  ../bin/busybox 50
  =>busybox is used, user is happy

then we run merge script (longer alternative file wins
=>sysvinit is used again, but without actuall /sbin/init.sysvinit file
in fs.. boot fails, user is sad. I think there is no way to distinguish
between T2b where newer shorter file is wrong and Tfsck where newer
shorter file is the right one (without checking opkg history..)

With images built before 2009-12-08 it should be simple
opkg/alternatives should be empty, all files from ipkg/alternatives are
just moved there..

Why would I like to add the same merge script to opkg?
1) someone maybe already removed -cworth from image with first sign of
   issues (but still too late) and -cworth postinst is still needed

2) task-boot will be fixed (RDEPEND on same u-a as
   virtual/update-alternatives-native) and user won't get -cworth update.

3) If I get new -cworth and busybox in one opkg upgrade batch, then I'm
   not sure which postinst will be executed first (we need -cworth first),
   but opkg maybe run own postinst before configuring other packages (ie
   portage does that completely even with restart of upgrade process)

Updated -cworth is already used in SHR (from shr/merge branch).

My shell foo is maybe not strong enough to check that everything is available 
in all environments and no bashisms were used..)

Thanks and please comment (I'll resend whole patch serie as soon as
someone confirms that's good path to go).

Regards,

-- 
uin:136542059                jid:Martin.Jansa at gmail.com
Jansa Martin                 sip:jamasip at voip.wengo.fr 
JaMa