Re: [yocto] [opkg-devel] [opkg-utils] Question: why update-alternatives from opkg-utils chooses /usr/lib to hold database?
On Wed, Mar 6, 2019 at 11:37 PM Mark Hatle wrote: > > On 3/5/19 10:44 PM, Alex Kiernan wrote: > > On Tue, Mar 5, 2019 at 10:50 PM Richard Purdie > > wrote: > >> > >> On Tue, 2019-03-05 at 16:05 +, 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. > > > > 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? > No. > 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. > Sounds like our use case is similar... variation is exactly what we're trying to avoid, so we don't allow changes like that. > 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. > I'd agree, it's clearly valuable for some, it's just how you accommodate both. I guess so long as it's still changeable, it's not a problem. -- Alex Kiernan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [opkg-devel] [opkg-utils] Question: why update-alternatives from opkg-utils chooses /usr/lib to hold database?
On 3/5/19 10:44 PM, Alex Kiernan wrote: > On Tue, Mar 5, 2019 at 10:50 PM Richard Purdie > wrote: >> >> On Tue, 2019-03-05 at 16:05 +, 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. > 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. --Mark -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [opkg-devel] [opkg-utils] Question: why update-alternatives from opkg-utils chooses /usr/lib to hold database?
On Tue, Mar 5, 2019 at 10:50 PM Richard Purdie wrote: > > On Tue, 2019-03-05 at 16:05 +, 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 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [opkg-devel] [opkg-utils] Question: why update-alternatives from opkg-utils chooses /usr/lib to hold database?
On Tue, 2019-03-05 at 16:05 +, 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.. Cheers, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [opkg-devel] [opkg-utils] Question: why update-alternatives from opkg-utils chooses /usr/lib to hold database?
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 > Best Regards, > Chen Qi > -- Cheers, Alejandro -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto