On Aug 12, 2009, at 12:25 PM, "Benjamin M. Schwartz" wrote:
> Indeed. The #1 thing to do, IMHO, is to get rid of the "yum install"
> requirement. In the short term, the only way to do that is to bundle
> gtk-vnc and gtk-vnc-python into the .xo, which is fine... I'm just not
> quite sure how to
Brian Jordan wrote:
>
> On Aug 12, 2009, at 12:25 PM, "Benjamin M. Schwartz"
> wrote:
>
>> Indeed. The #1 thing to do, IMHO, is to get rid of the "yum install"
>> requirement. In the short term, the only way to do that is to bundle
>> gtk-vnc and gtk-vnc-python into the .xo, which is fine... I
On Wed, Aug 12, 2009 at 12:59 PM, Benjamin M.
Schwartz wrote:
> Brian Jordan wrote:
>>
>> On Aug 12, 2009, at 12:25 PM, "Benjamin M. Schwartz"
>> wrote:
>>
>>> Indeed. The #1 thing to do, IMHO, is to get rid of the "yum install"
>>> requirement. In the short term, the only way to do that is to b
>> Indeed. The #1 thing to do, IMHO, is to get rid of the "yum install"
>> requirement. In the short term, the only way to do that is to bundle
>> gtk-vnc and gtk-vnc-python into the .xo, which is fine... I'm just not
>> quite sure how to do it.
>
> If someone does know how to do this sort of thi
Peter Robinson wrote:
>>> Indeed. The #1 thing to do, IMHO, is to get rid of the "yum install"
>>> requirement. In the short term, the only way to do that is to bundle
>>> gtk-vnc and gtk-vnc-python into the .xo, which is fine... I'm just not
>>> quite sure how to do it.
>> If someone does know h
On Mon, Aug 17, 2009 at 8:40 PM, Peter Robinson wrote:
>> If someone does know how to do this sort of thing, a quick how-to
>> writeup would be immensely useful!
>
> Please DON'T do this. There is absolutely NO guarantee that this will
...
> If you have something that
> has a dependency you'd be mu
Indeed. The #1 thing to do, IMHO, is to get rid of the "yum install"
requirement. In the short term, the only way to do that is to bundle
gtk-vnc and gtk-vnc-python into the .xo, which is fine... I'm just not
quite sure how to do it.
>>> If someone does know how to do this sor
Hi Martin,
>> Please DON'T do this. There is absolutely NO guarantee that this will
> ...
>> If you have something that
>> has a dependency you'd be much better to package it up as an rpm where
>> you can do proper rpm requires which means it can pull in any required
>> dependencies. I will quite
> Indeed. The #1 thing to do, IMHO, is to get rid of the "yum install"
> requirement. In the short term, the only way to do that is to bundle
> gtk-vnc and gtk-vnc-python into the .xo, which is fine... I'm just not
> quite sure how to do it.
If someone does know how to do thi
> I assume you know that when users are installing Sugar 'activities'
> they don't have root access, and that the install is completely in ~
> ...
>
> If we get on the "do the right thing" horse, then we have to ensure
> user-installable RPMs ("relocatable" I think is the feature name) are
> workin
On Mon, Aug 17, 2009 at 15:48, Mathieu Bridon (bochecha) <
boche...@fedoraproject.org> wrote:
> PackageKit uses PolicyKit for the authentication framework, which
> means you can very easily define the following permissions:
>
> 1. user A can install signed RPMs from the repositories without root
>
On Mon, Aug 17, 2009 at 21:52, Luke Faraone wrote:
> On Mon, Aug 17, 2009 at 15:48, Mathieu Bridon (bochecha)
> wrote:
>>
>> PackageKit uses PolicyKit for the authentication framework, which
>> means you can very easily define the following permissions:
>>
>> 1. user A can install signed RPMs from
Mathieu Bridon (bochecha) wrote:
> (and « because we can't ask the user the root password » is not a
> valid excuse, see PolicyKit)
In an LTSP environment, no sysadmin is going to choose a policy that
allows users to install packages, even trusted packages, to the root
system, or otherwise make an
> In an LTSP environment, no sysadmin is going to choose a policy that
> allows users to install packages, even trusted packages, to the root
> system, or otherwise make any sort of modification that cannot be
> trivially and reliably wiped clean. PolicyKit will work fine, in that it
> will happil
Peter Robinson wrote:
>> In an LTSP environment, no sysadmin is going to choose a policy that
>> allows users to install packages, even trusted packages, to the root
>> system, or otherwise make any sort of modification that cannot be
>> trivially and reliably wiped clean. PolicyKit will work fine
Hi Peter,
On 17 Aug 2009, at 21:20, Peter Robinson wrote:
>> In an LTSP environment, no sysadmin is going to choose a policy that
>> allows users to install packages, even trusted packages, to the root
>> system, or otherwise make any sort of modification that cannot be
>> trivially and reliably
> The whole point is a learner/teacher can modify any activity at any time and
> then share that modification in a safe, sandboxed way, to other Sugar users
> (and perhaps back to us). No existing packaging systems seem to have any
> concept of this basic Sugar feature/goal :-(
Don't the .xo packa
On Mon, Aug 17, 2009 at 10:34 PM, Gary C Martin wrote:
> Hi Peter,
>
> On 17 Aug 2009, at 21:20, Peter Robinson wrote:
>
>>> In an LTSP environment, no sysadmin is going to choose a policy that
>>> allows users to install packages, even trusted packages, to the root
>>> system, or otherwise make an
On Mon, Aug 17, 2009 at 03:18:22PM -0400, Benjamin M. Schwartz wrote:
> So, in fact, I have taken a middle way that is somewhat interesting.
> [...]
> It then generates these variables so as to ensure that the bundles
> libraries are inserted with _lowest_ priority, rather than _highest_
> priority
On 17.08.2009, at 23:34, Gary C Martin wrote:
> For the Mac users, it's just "Drag this application to your
> application folder." Done, end of story. For the worst application
> offenders (and there are some, usually some of the big corps who can
> get away with it) the user is asked for their ad
Hi Bert,
On 18 Aug 2009, at 09:10, Bert Freudenberg wrote:
> On 17.08.2009, at 23:34, Gary C Martin wrote:
>
>> For the Mac users, it's just "Drag this application to your
>> application folder." Done, end of story. For the worst application
>> offenders (and there are some, usually some of the b
As a linux user much of my life and an OS X user for the past year, I
dearly miss package management. Self-contained bundles are ok as far
as they have minimal dependencies besides the existing platform
libraries. When you simply bundle everything, you get 100MB+ bundles
for pretty much everything
22 matches
Mail list logo
