[yocto] [opkg-devel] [opkg-utils] Question: why update-alternatives from opkg-utils chooses /usr/lib to hold database?
mark.hatle at windriver.com
Wed Mar 6 15:37:14 PST 2019
On 3/5/19 10:44 PM, Alex Kiernan wrote:
> On Tue, Mar 5, 2019 at 10:50 PM Richard Purdie
> <richard.purdie at linuxfoundation.org> wrote:
>> On Tue, 2019-03-05 at 16:05 +0000, Alejandro Del Castillo wrote:
>>> On 3/5/19 12:11 AM, ChenQi wrote:
>>>> Hi All,
>>>> Recently I'm dealing with issue from which some discussion raises.
>>>> I'd like to ask why update-alternatives from opkg-utils chooses
>>>> to hold its alternatives database?
>>>> I looked into debian, its update-alternatives chooses /var/lib by
>>>> Is there some design consideration? Or some historical reason?
>>> Update-alternatives used to be on the opkg repo. I did a search
>>> all the way to the first commit on 2008-12-15 , but even then
>>> /usr/lib was used. I can't think of a design consideration that
>>> make /usr/lib more palatable than the Debian default.
>>> Maybe someone with more knowledge of the previous history can chime
>> I think the history is that the whole of /var was considered volatile
>> and we wanted the alternatives data to stick around so it was put under
>> That decision doesn't really make sense now since only parts of /var
>> are volatile..
> I don't use opkg (or in fact any package manager on a target), but I
> do use OSTree, where my /var isn't part of what gets deployed to a
> device (https://ostree.readthedocs.io/en/latest/manual/adapting-existing/#adapting-existing-package-managers)
> so having the option to keep it in /usr would be important to anyone
> who has mechanisms like that.
Do you allow a device that has been sent an update via OSTree to then run
update-alternatives to change what has been set by the update mechanism?
In my own uses of both OSTree and update-alternatives, I set this on a global
basis and use it that way. So no individual user (device) would be different
then what was globally sent out.
If this is desired, then continuing to have a mechanism to allow it to be
overridden for legacy or your purposes seems reasonable... but I think moving
the default still makes a lot of sense.
More information about the yocto