Hello Olivier, On Tue, Mar 17, 2009 at 02:36:02PM +0100, Olivier Tilloy wrote: > Thanks, and sorry for the late reply. Have you checked out the latest > release (0.5.32)?
I have, and also 0.5.33 by now. ;) > > I am one of the Debian Elisa maintainers and am not sure how to deal > > with the update system yet. I've talked about it with some of you > > on the IRC, but it might be better to discuss it here. > > Indeed there is a lot to be discussed. > > > It seems there are a few issues here: > > > > 1) There are plugins that are not distributed via -good, bad, or -ugly > > AFAIK (apple_trailers, ted, etc.). For this the plugin (update) > > system is essentially an installer for extra functionality that users > > can select. If these plugins are never pulled into -good, -bad or > > -ugly, they should be updated once the user installs them. Either > > that, or we start distributing these plugins also. > > The plugin distributed externally are indeed never going to be shipped > in -good, -bad, -ugly. In fact for some of them (and we hope most of > them in the future) we don't even ship them, just link to them in our > plugin repository. That allows us to easily bring to the users the best > of the community developments. > Now, I would say that's up to each distro to decide whether they find > some external plugins good and interesting enough (and > license-compatible) to ship them in external packages. I plan to package some of the plugins, as long as there is not demand, I see no problem there. So, I think we can agree that even for an Elisa instance distributed by some distribution such as Debian, plugins still need to be available. That's why I haven't set update_plugin_cache to False, just doesn't feel right to do so. > > 2) [...] Does Elisa to plugin cleaning? > > Currently not, that's something we need to implement. See > https://bugs.launchpad.net/elisa/+bug/309161. Ah, ok.. subscribed. > > 3) Is Elisa aware of plugins (including the core) being not user but > > distribution installed? > > Yes. Basically, at startup plugins are going to be searched in the > PYTHONPATH + ~/.elisa-0.5/plugins/. > If a more recent version of a distribution installed plugin is found in > ~/.elisa-0.5/plugins/, it is going to supersede it. Right. But since people can arbitrarily change PYTHONPATH, there is not a real two-step search of dist plugins and then user plugins. So, it's not so easy to do as I initially thought. > > If (3) is the case, we could maybe have an mode between completely > > unawareness of any plugin updates at all and full plugin upgrades and > > access to new plugins that Elisa has now, namely a 'dist' mode where > > dist plugins are never upgraded, only new plugins can be installed and > > updated. Also plugins that become 'dist' plugins at some point can be > > cleaned automatically. > > That's a possibility indeed, that would require some modifications to > the plugin registry. In fact I want to clean it up at some point, and > this feature could be implemented at this point. Can you please open a > bug report explaining the idea, and assign it to me? So I've thought about this more. And it seems quite an elegant solution to me. At build time the eggs get the extra metadata flag 'dist' or 'vendor', and when newer versions of the same plugin are found they are discarded or the 'dist' one is considered the newest. Either way, this would result in only adapting the "comparision function". However, I am unaware of the current implementation. Should I write the above in the bug report? Let me know. :) For me, not being able to block updates of these 'dist' plugins is the main issue that prevents me uploading Elisa 0.5.x to Debian Sid. So, I hope we can work out the above the idea or something completely different. Even a temporary solution is fine, it doesn't have to be perfect in one attempt, right? :) Kind regards, Paul -- PhD Student @ Eindhoven | email: [email protected] University of Technology, The Netherlands | JID: [email protected] >>> Using the Power of Debian GNU/Linux <<< | GnuPG key ID: 0x50064181
