Three goals for this feature are stated below. Any comment or suggestion is welcome. 1. Fix opkg's update-alternatives to make it handle on-device upgrade correctly. 2. Avoid circular dependency when using dpkg's update-alternative as PREFERRED_PROVIDER_virtual/update-alternatives. At the very least, we should disallow users to make such configurations. 3. Make dpkg's update-alternatives have actual effect on target. For now, setting VIRTUAL-RUNTIME_update-alternatives to 'update-alternatives-dpkg' will result in errors when using the update-alternatives command on target, because dpkg and opkg's database for update-alternatives are not compatible. Below is a few backgrounds for this bug. A few days ago, Martin pointed out an upgrade error of busybox. ''' update-alternatives: Error: cannot register alternative addgroup to /usr/sbin/addgroup since it is already registered to /bin/addgroup update-alternatives: Error: cannot register alternative adduser to /usr/sbin/adduser since it is already registered to /bin/adduser ''' The real problem here is that opkg's update-alternatives has a simple assumption in its design, that is, the links for the same command should be the same. Note that it's not unusual to create symlinks with update-alternatives in OE/Yocto. So my conclusion is opkg's update-alternatives should at least handle this situation, as it may indicate a package upgrade. Then I explored the status of update-alternatives in OE and found the flaws stated above. //Chen Qi
I've ran into a similar circular dependency loop as (2) in Chen's description when adding optional dependencies to opkg with PACKAGECONFIG options. Enabling curl support within opkg requires a dependency on curl. curl in turn depends on ncurses (via a few intermediate dependencies) and ncurses uses update-alternatives causing a dependency on virtual/update-alternatives. PREFERRED_PROVIDER_virtual/update-alternatives is set to "opkg" in meta/conf/distro/include/default-providers.inc and so we have a dependency loop if curl is enabled via the new PACKAGECONFIG options for opkg. This places quite a constraint on whichever recipe PROVIDES update-alternatives. Going forward I'm hoping to use libarchive within opkg and libarchive depends on bzip2 by default which uses update-alternatives, which would cause the same problem. We may benefit from splitting update-alternatives off into its own recipe which should have minimal dependencies.
(1) in Chen's initial report is now entered as an opkg bug: https://code.google.com/p/opkg/issues/detail?id=113
*** Bug 5708 has been marked as a duplicate of this bug. ***
So, some of what I posted has been fixed by moving update-alternatives from opkg to opkg-utils. What remains is: 1. Fix opkg's update-alternatives to make it handle on-device upgrade correctly. How can we differentiate the case of two programs, one in /usr/bin and one in /usr/sbin but having the same name, both wanting to use update-alternatives but be independent from the case where it is a single program that has moved from /usr/bin to /usr/sbin? 2. Avoid circular dependency when using dpkg's update-alternative as PREFERRED_PROVIDER_virtual/update-alternatives. At the very least, we should disallow users to make such configurations. Both update-alternatives-dpkg and update-alternatives-chkconfig don't seem to work due to circular dependencies when they are set as the update-alternatives provider. We can either look at fixing this or to remove these as update-alternatives providers. Someone needs to make a decision. 3. Make dpkg's update-alternatives have actual effect on target. For now, setting VIRTUAL-RUNTIME_update-alternatives to 'update-alternatives-dpkg' will result in errors when using the update-alternatives command on target, because dpkg and opkg's database for update-alternatives are not compatible. I don't think we'll be able to support changing the update-alternatives provider for an existing image. update-alternatives-opkg is designed to use less disk space to store it's config (that's my understanding at least) and so it would defeat the objective to make its database compatible with the update-alternatives-dpkg database. Also, update-alternatives-dpkg doesn't support offline root (to my knowledge) and fixing this would require patching their update-alternatives program and could be a significant amount of work (I don't know how much). Hope this input is useful!
I've just had a quick look at update-alternatives.pl from dpkg. When running `update-alternatives --install $link $name $path $priority`, if $name already exists with a different path for $link, it moves the link from the old path to the new one and updates its database. Is that the behaviour we want?
Re comment 5: This does look suspect to me. As the link (target) should be consistent. There is a case (busybox) where different links will be created all pointing back to the single busybox executable. Will this fail with what you discovered?
I'm referring to the situation where a package upgrade or a new package install causes a link to be moved. Eg, A does 'update-alternatives --install /bin/app app /some/real/path 100' Then B does 'update-alternatives --install /sbin/app app /some/other/path 100' Debian's update alternatives assumes that the second command should move the link created by the first command to the location specified in the second command. ie. It assumes B is an upgrade of A. Currently, opkg's update-alternatives errors out. So in this situation, should we follow the Debian behaviour and assume this indicates an upgrade (which is probably does), should we keep reporting an error, or should we do something else?
Ahh, I misunderstood. I think the behavior is reasonable then.
Sorry to be pedantic but which behaviour do you think is reasonable, the current opkg behaviour (error out) or the Debian behaviour (move the symlink)? Chen Qi's first comment shows an example of the error as seen during a busybox upgrade.
I'm sorry it was a long day. Changing the symlink in a -system- level upgrade is reasonable. On a per-package basis through it should be an error... so we need to compromise and figure out the right answer. (I suspect the answer is the Debian behavior, because system level upgrades are becoming more desired.) So my suggestion is. We somehow verify that within a given distribution build the link behavior is consistent among all of the update-alternative users. Then we allow for the Debian behavior as "expected".
Hi Saul, What do you think of this problem? The situation here is that for now only opkg-utils provides *valid* update-alternatives for our system. From my point of view, we have to ways to deal with this problem. 1) Remove related statements in chkconfig and dpkg recipes to avoid confusing users. In other words, we don't let chkconfig and dpkg provide virtual/update-alternatives. (I think the bottom line is that we should not claim features that we actually don't provide.) 2) Make chkconfig and dpkg's update-alternatives also valid for our system. We need to resolve the circular dependency problem, also, we need to add support of offline mode for these update-alternatives. What do you think? Best Regards, Chen Qi
Regarding 'Both update-alternatives-dpkg and update-alternatives-chkconfig don't seem to work due to circular dependencies when they are set as the update-alternatives provider. We can either look at fixing this or to remove these as update-alternatives providers. Someone needs to make a decision.', MEL has been using chkconfig's update-alternatives for both native and on-target for some time. Admittedly, we don't do much package upgrade testing, so I'm not sure about that, but any circular dependency situation must have been fixed, as we don't hit that at all.
is this fixed now?
I'd note that dpkg and opkg-utils both provide update-alternative mechanisms so we need to work out if the issues raised in this bug still apply to those.