On Fri, Aug 8, 2014 at 11:41 PM, Saul Wold wrote:
> On 08/08/2014 02:37 AM, Sujith H wrote:
>
>> From: Sujith H
>>
>> This is needed to deal with the situation where we're using ipk
>> packaging, so
>> opkg-utils must be built regardless of what update-alternatives provider
>> we
>> prefer. The
From: Sujith H
This is needed to deal with the situation where we're using ipk packaging, so
opkg-utils must be built regardless of what update-alternatives provider we
prefer. The downside to the current implementation is the need to adjust
PACKAGECONFIG as well as PREFERRED_PROVIDER, but it is
On 08/08/2014 02:37 AM, Sujith H wrote:
From: Sujith H
This is needed to deal with the situation where we're using ipk packaging, so
opkg-utils must be built regardless of what update-alternatives provider we
prefer. The downside to the current implementation is the need to adjust
PACKAGECONFIG
From: Sujith H
This is needed to deal with the situation where we're using ipk packaging, so
opkg-utils must be built regardless of what update-alternatives provider we
prefer. The downside to the current implementation is the need to adjust
PACKAGECONFIG as well as PREFERRED_PROVIDER, but it is
On 08/07/2014 02:24 AM, Sujith H wrote:
From: Sujith H
This is needed to deal with the situation where we're using ipk packaging, so
opkg-utils must be built regardless of what update-alternatives provider we
prefer. The downside to the current implementation is the need to adjust
PACKAGECONFIG
Hi Paul Eggleton,
On Thu, Aug 7, 2014 at 2:54 PM, Sujith H wrote:
> From: Sujith H
>
> This is needed to deal with the situation where we're using ipk packaging,
> so
> opkg-utils must be built regardless of what update-alternatives provider we
> prefer. The downside to the current implementat
From: Sujith H
This is needed to deal with the situation where we're using ipk packaging, so
opkg-utils must be built regardless of what update-alternatives provider we
prefer. The downside to the current implementation is the need to adjust
PACKAGECONFIG as well as PREFERRED_PROVIDER, but it is
On Wednesday 06 August 2014 18:58:11 sujith h wrote:
> On Wed, Aug 6, 2014 at 6:08 PM, Paul Eggleton > wrote:
> >
> > On Wednesday 06 August 2014 17:34:09 Sujith H wrote:
> > > From: Sujith H
> > >
> > > This is needed to deal with the situation where we're using ipk
> >
> > packaging,
> >
>
On Wed, Aug 6, 2014 at 6:08 PM, Paul Eggleton wrote:
> On Wednesday 06 August 2014 17:34:09 Sujith H wrote:
> > From: Sujith H
> >
> > This is needed to deal with the situation where we're using ipk
> packaging,
> > so opkg-utils must be built regardless of what update-alternatives
> provider
>
On Wednesday 06 August 2014 17:34:09 Sujith H wrote:
> From: Sujith H
>
> This is needed to deal with the situation where we're using ipk packaging,
> so opkg-utils must be built regardless of what update-alternatives provider
> we prefer. The downside to the current implementation is the need to
From: Sujith H
This is needed to deal with the situation where we're using ipk packaging, so
opkg-utils must be built regardless of what update-alternatives provider we
prefer. The downside to the current implementation is the need to adjust
PACKAGECONFIG as well as PREFERRED_PROVIDER, but it is
From: Sujith H
This is needed to deal with the situation where we're using ipk packaging, so
opkg-utils must be built regardless of what update-alternatives provider we
prefer. The downside to the current implementation is the need to adjust
PACKAGECONFIG as well as PREFERRED_PROVIDER, but it is
12 matches
Mail list logo
