On Tue, Jul 28, 2009 at 09:00:49AM +, Aleksey Lim wrote:
> On Tue, Jul 28, 2009 at 01:49:15PM +0545, Daniel Drake wrote:
> > 2009/7/28 Aleksey Lim :
> > > Proposal is not about storing all versions but about possibility of
> > > storing not only one(last?) version and we can uninstall old versi
On Tue, Jul 28, 2009 at 04:19:15PM -0700, Edward Cherlin wrote:
> Sugar on a Stick currently [has Fructose Activities installed] from
> packages
This has changed now in SoaS and F11-on-XO, which both now just use
.xos for Fructose and other non-Glucose activities.
Martin
pgphc53u8MLGc.pgp
Desc
On Mon, Jul 27, 2009 at 11:39 PM, Daniel Drake wrote:
> 2009/7/28 Aleksey Lim :
>> The problems that 0.84 has in case of activity versions are:
>>
>> * it can't upgrade activities if they were pre-installed from
>> native packages; it makes process of upgrading activities
>> from .xo impossible
>
On Tue, Jul 28, 2009 at 1:39 AM, Daniel Drake wrote:
> 2009/7/28 Aleksey Lim :
>> The problems that 0.84 has in case of activity versions are:
>>
>> * it can't upgrade activities if they were pre-installed from
>> native packages; it makes process of upgrading activities
>> from .xo impossible
>
On Tue, Jul 28, 2009 at 01:01:32PM +0200, Sascha Silbe wrote:
> On Tue, Jul 28, 2009 at 10:37:18AM +, Aleksey Lim wrote:
>
> >Since [3] is(in addition) an idea of having "composite" Journal
> >objects(when we have content of bundle stored somewhere in form of
> >ready to use directly, and this
Daniel Drake writes:
> Finally, I personally don't like the idea of having activities
> (as in applications) in the journal. The journal is for
> recording what the user has done.
I think that **uninstalled** activities belong in the journal.
An activity can be in the journal like any random data
On Tue, Jul 28, 2009 at 13:36, Sascha
Silbe wrote:
> On Tue, Jul 28, 2009 at 12:59:43PM +0200, Tomeu Vizoso wrote:
>
>>> The more important point is that it also works for people installing
>>> Sugar
>>> from packages on their own system, without manual symlink fiddling. My
>>> imagined use case is
On Tue, Jul 28, 2009 at 12:59:43PM +0200, Tomeu Vizoso wrote:
The more important point is that it also works for people installing
Sugar
from packages on their own system, without manual symlink fiddling.
My
imagined use case is someone doing a "full" Sugar desktop
installation (by
using a cor
On Tue, Jul 28, 2009 at 10:37:18AM +, Aleksey Lim wrote:
Since [3] is(in addition) an idea of having "composite" Journal
objects(when we have content of bundle stored somewhere in form of
ready to use directly, and this content is represented by one Journal
item) we can treat activities like
On Tue, Jul 28, 2009 at 12:55, Sascha
Silbe wrote:
> On Tue, Jul 28, 2009 at 12:38:32PM +0200, Tomeu Vizoso wrote:
>
To avoid space duplication in LTSP environments, ~/Activities can
contain symlinks to somewhere in /usr if the deployer wants users to
be able to uninstall and upgrade
On Tue, Jul 28, 2009 at 12:38:32PM +0200, Tomeu Vizoso wrote:
To avoid space duplication in LTSP environments, ~/Activities can
contain symlinks to somewhere in /usr if the deployer wants users to
be able to uninstall and upgrade activities.
But this won't allow them to downgrade to the system-i
On Tue, Jul 28, 2009 at 12:30, Sascha
Silbe wrote:
> On Tue, Jul 28, 2009 at 12:18:58PM +0200, Tomeu Vizoso wrote:
>
>> To avoid space duplication in LTSP environments, ~/Activities can
>> contain symlinks to somewhere in /usr if the deployer wants users to
>> be able to uninstall and upgrade activ
On Tue, Jul 28, 2009 at 12:14:54PM +0200, Sascha Silbe wrote:
> On Tue, Jul 28, 2009 at 05:14:57AM +, Aleksey Lim wrote:
>
> >* it can't upgrade activities if they were pre-installed from
> > native packages; it makes process of upgrading activities
> > from .xo impossible
> Yeah, this is re
On Tue, Jul 28, 2009 at 12:18:58PM +0200, Tomeu Vizoso wrote:
To avoid space duplication in LTSP environments, ~/Activities can
contain symlinks to somewhere in /usr if the deployer wants users to
be able to uninstall and upgrade activities.
But this won't allow them to downgrade to the system-i
On Tue, Jul 28, 2009 at 12:14, Sascha
Silbe wrote:
> On Tue, Jul 28, 2009 at 05:14:57AM +, Aleksey Lim wrote:
>
>> * it can't upgrade activities if they were pre-installed from
>> native packages; it makes process of upgrading activities
>> from .xo impossible
>
> Yeah, this is really a PITA.
On Tue, Jul 28, 2009 at 05:14:57AM +, Aleksey Lim wrote:
* it can't upgrade activities if they were pre-installed from
native packages; it makes process of upgrading activities
from .xo impossible
Yeah, this is really a PITA.
* sugar can have only one activity version installed at the
On Tue, Jul 28, 2009 at 01:49:15PM +0545, Daniel Drake wrote:
> 2009/7/28 Aleksey Lim :
> > Proposal is not about storing all versions but about possibility of
> > storing not only one(last?) version and we can uninstall old versions
> > by removing entries from journal.
>
> The journal can't dele
2009/7/28 Aleksey Lim :
> Proposal is not about storing all versions but about possibility of
> storing not only one(last?) version and we can uninstall old versions
> by removing entries from journal.
The journal can't delete activities that are installed by a package at
/usr/share/activities, an
On Tue, Jul 28, 2009 at 12:24:52PM +0545, Daniel Drake wrote:
> 2009/7/28 Aleksey Lim :
> > The problems that 0.84 has in case of activity versions are:
> >
> > * it can't upgrade activities if they were pre-installed from
> > native packages; it makes process of upgrading activities
> > from .xo
2009/7/28 Aleksey Lim :
> The problems that 0.84 has in case of activity versions are:
>
> * it can't upgrade activities if they were pre-installed from
> native packages; it makes process of upgrading activities
> from .xo impossible
In reality Sugar's message is confusing here and I don't thin
20 matches
Mail list logo
