[packagekit] ServicePack: The magic file

[David Zeuthen]

On Fri, 2008-03-28 at 10:07 +0000, Richard Hughes wrote:
> On Thu, 2008-03-27 at 23:38 -0400, David Zeuthen wrote:
> >  - Security: I'm not sure you should be adding repositories without
> > the users consent.
> 
> Well, I think adding disabled repositories is fine - they are going to
> be ignored until the user trusts the media is valid, and the session
> enables the repo.

What is the point of doing this?

> > Implementation-wise this is even simpler. You don't need to pollute the
> > main daemon with extra code or dependencies.
> 
> I see two issues with the session only solution:
> 
> * How do we Lock() the CDROM drive to stop the user pressing eject or
> unmounting the volume? We would loose the lock anytime we do a fast user
> switch.

Why would you need to do this? By the same token do you Lock() the
network connection on NetworkManager when using a networked repo?

> * Even if we catch the ::unmount signal in the session from gvfs, the
> repo still is added and enabled. If we shutdown after doing an install
> from the media, then remove the disk when there is no power, then the
> repo is still valid. When we reboot, the backend is going to complain
> loudly that it can't find /media/disk/Fedora/Updates/metadata.xml

Hmmm.. It seems to me like yum or your backend should handle this
gracefully anyway, yes? 

E.g. when writing out the [repository] entry you should be able to set a
key: dont_complain_about_missing_media=1. Or if you can't get the yum
developers to give you such an option just make your own backend sanity
check that the repo exists before handing control over to yum. The user
will be able to add it back next time he inserts the media so this is
probably fine.

The point here is that we don't have to handle ::unmount in real-time.
We can either sanity the repo list before it is used. Or we can teach
the actual depsolver about handling it gracefully. That's a lot simpler.

     David