* [opkg-utils] Question: why update-alternatives from opkg-utils chooses /usr/lib to hold database?
@ 2019-03-05 6:11 ChenQi
2019-03-05 16:05 ` [opkg-devel] " Alejandro Del Castillo
0 siblings, 1 reply; 6+ messages in thread
From: ChenQi @ 2019-03-05 6:11 UTC (permalink / raw)
To: opkg-devel, yocto
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?
Best Regards,
Chen Qi
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [opkg-devel] [opkg-utils] Question: why update-alternatives from opkg-utils chooses /usr/lib to hold database?
2019-03-05 6:11 [opkg-utils] Question: why update-alternatives from opkg-utils chooses /usr/lib to hold database? ChenQi
@ 2019-03-05 16:05 ` Alejandro Del Castillo
2019-03-05 22:50 ` Richard Purdie
0 siblings, 1 reply; 6+ messages in thread
From: Alejandro Del Castillo @ 2019-03-05 16:05 UTC (permalink / raw)
To: opkg-devel, ChenQi, yocto
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [opkg-devel] [opkg-utils] Question: why update-alternatives from opkg-utils chooses /usr/lib to hold database?
2019-03-05 16:05 ` [opkg-devel] " Alejandro Del Castillo
@ 2019-03-05 22:50 ` Richard Purdie
2019-03-06 4:44 ` Alex Kiernan
0 siblings, 1 reply; 6+ messages in thread
From: Richard Purdie @ 2019-03-05 22:50 UTC (permalink / raw)
To: Alejandro Del Castillo, opkg-devel, ChenQi, yocto
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..
Cheers,
Richard
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [opkg-devel] [opkg-utils] Question: why update-alternatives from opkg-utils chooses /usr/lib to hold database?
2019-03-05 22:50 ` Richard Purdie
@ 2019-03-06 4:44 ` Alex Kiernan
2019-03-06 23:37 ` Mark Hatle
0 siblings, 1 reply; 6+ messages in thread
From: Alex Kiernan @ 2019-03-06 4:44 UTC (permalink / raw)
To: Richard Purdie; +Cc: yocto, opkg-devel
On Tue, Mar 5, 2019 at 10:50 PM Richard Purdie
<richard.purdie@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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [opkg-devel] [opkg-utils] Question: why update-alternatives from opkg-utils chooses /usr/lib to hold database?
2019-03-06 4:44 ` Alex Kiernan
@ 2019-03-06 23:37 ` Mark Hatle
2019-03-07 0:03 ` Alex Kiernan
0 siblings, 1 reply; 6+ messages in thread
From: Mark Hatle @ 2019-03-06 23:37 UTC (permalink / raw)
To: Alex Kiernan, Richard Purdie; +Cc: yocto, opkg-devel
On 3/5/19 10:44 PM, Alex Kiernan wrote:
> On Tue, Mar 5, 2019 at 10:50 PM Richard Purdie
> <richard.purdie@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.
>
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [opkg-devel] [opkg-utils] Question: why update-alternatives from opkg-utils chooses /usr/lib to hold database?
2019-03-06 23:37 ` Mark Hatle
@ 2019-03-07 0:03 ` Alex Kiernan
0 siblings, 0 replies; 6+ messages in thread
From: Alex Kiernan @ 2019-03-07 0:03 UTC (permalink / raw)
To: Mark Hatle; +Cc: yocto, opkg-devel
On Wed, Mar 6, 2019 at 11:37 PM Mark Hatle <mark.hatle@windriver.com> wrote:
>
> On 3/5/19 10:44 PM, Alex Kiernan wrote:
> > On Tue, Mar 5, 2019 at 10:50 PM Richard Purdie
> > <richard.purdie@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.
> >
>
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-03-07 0:03 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-05 6:11 [opkg-utils] Question: why update-alternatives from opkg-utils chooses /usr/lib to hold database? ChenQi
2019-03-05 16:05 ` [opkg-devel] " Alejandro Del Castillo
2019-03-05 22:50 ` Richard Purdie
2019-03-06 4:44 ` Alex Kiernan
2019-03-06 23:37 ` Mark Hatle
2019-03-07 0:03 ` Alex Kiernan
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.