[yocto] [opkg-devel] [opkg-utils] Question: why update-alternatives from opkg-utils chooses /usr/lib to hold database?

[Alex Kiernan]

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
> > > /usr/lib
> > > to hold its alternatives database?
> > > I looked into debian, its update-alternatives chooses /var/lib by
> > > default.
> > > Is there some design consideration? Or some historical reason?
> >
> > Update-alternatives used to be on the opkg repo. I did a search
> > there
> > all the way to the first commit on 2008-12-15 [1], but even then
> > /usr/lib was used. I can't think of a design consideration that
> > would
> > make /usr/lib more palatable than the Debian default.
> >
> > Maybe someone with more knowledge of the previous history can chime
> > in?
> >
> > [1]
> > http://git.yoctoproject.org/clean/cgit.cgi/opkg/commit/?id=8bf49d16a637cca0cd116450dfcabc4c941baf6c
>
> 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
> /usr.
>
> 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.

-- 
Alex Kiernan