[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: PackageKit policy: background and plans



On Mon, 2009-11-23 at 18:32 -0500, Seth Vidal wrote:
> 
> On Mon, 23 Nov 2009, Colin Walters wrote:
> 
> > On Mon, Nov 23, 2009 at 10:02 PM, James Morris <jmorris namei org> wrote:
> >>
> >>
> >> Possibly (it could simply be that an updated policy is weaker for some
> >> reason) -- but it doesn't matter, there should be no way to change MAC
> >> policy without MAC privilege.
> >
> > It'd be nice here if we had the ability to only grant the ability to
> > install applications, not packages.  We could possibly do this even
> > now inside PackageKit by always downloading the filelists data, and
> > looking for a .desktop file.  It'd be even better if we could get at
> > the data inside the .desktop file, but that's not necessary for this.
> > That leaves aside the packagekit-command-not-found feature for unix
> > binaries, but that's more of a technical use case.
> 
> Or - you could more easily generate the 'which pkgs have .desktop files' 
> and propagate that into a package Provides.
> 
> since yum can install by provides - that takes care of that need.
> 
> example:
> 
> Provides: App('foo')
> 
> -sv


Would it be possible to do this similarly to Conary... only installing
the files (.so's and things in /etc and /usr/share/{icons,sounds,...}
etc) required by a given application (binary with .desktop file) ?

This would provide similar to package splitting, but because of version
control and something like google update, it can be effective to update
only those files and applications when its parts are updated upstream...
with something like presto only bringing in what changed, and something
like jigdo allowing you to download each file from a different mirror,
speeds can be quite quick and downloads quite small.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]