Installing specific packages on demand (was: Re: proposal: remove KTextEditor interface from kdelibs repository)
Mardi, le 1 février 2011, à 19:39, Sune Vuorela a écrit: On 2011-02-01, Friedrich W. H. Kossebau kosse...@kde.org wrote: And I'm not sure there should be such a thing. Hm. You don't agree that a user experience like Sorry, missing X to do Y. Would you like to get X now for that? is better than one à la Na, no way to do Y.? Yes. since we can't assume the user has the right to install to the system directory, We can't assume for all, but in many installations the user does. Like the ususal private computer. For administrated systems, there could be a substitute which instead of allowing to install rather aids the user to file a request to the admin, for convenience and getting things done. and we shouldn't set up a complete development environment for him. I was thinking of interfacing to the normal packaging system of the system. He, something like DrKonqi installing the debug info packages on request. So something like that is existing already, just needs to be generalized perhaps. Cheers Friedrich -- Desktop Summit 2011 - Berlin, Germany - August 6-12th - www.desktopsummit.org
Re: Installing specific packages on demand
Mardi, le 1 février 2011, à 20:10, Sune Vuorela a écrit: On 2011-02-01, Friedrich W. H. Kossebau kosse...@kde.org wrote: We can't assume for all, but in many installations the user does. Like the ususal private computer. For administrated systems, there could be a substitute which instead of allowing to install rather aids the user to file a request to the admin, for convenience and getting things done. and we shouldn't set up a complete development environment for him. I was thinking of interfacing to the normal packaging system of the system. He, something like DrKonqi installing the debug info packages on request. So something like that is existing already, just needs to be generalized perhaps. Basically, a piece of software than have three relations: 1) Required things 2) Optional things that should be availably by default 3) optional things that doesn't need to be available by default Packagers should assure that 1) is around. Packagers should try hard to make 2) available for all not uncommon installations. if 1) is missing, file bugs at the distribution. if 2) is missing, file bugs at the distribution or alternatively tell the user you broke your system, you get to keep the pieces. And then there is the handling of 3). Well.. let's not make it a bigger issue than it actually is. Ah, Sune, guess we were missing each other :) I was talking of currently not installed optional things. And not speaking of optional things not existing as packages. E.g. imagine someone installing some program over an expensive/slow connection (think mobile). She just installs the required things, to keep the needed bandwith low. Then hits a feature which is more useful with some optional thing X. Ideally the feature's code would be able to offer the action Trigger install of optional thing X to pimp doing Y. Does this help to understand what I am looking forward to? Cheers Friedrich -- Desktop Summit 2011 - Berlin, Germany - August 6-12th - www.desktopsummit.org
Re: Installing specific packages on demand (was: Re: proposal: remove KTextEditor interface from kdelibs repository)
On Tue, Feb 1, 2011 at 1:55 PM, Friedrich W. H. Kossebau kosse...@kde.org wrote: Mardi, le 1 février 2011, à 19:39, Sune Vuorela a écrit: On 2011-02-01, Friedrich W. H. Kossebau kosse...@kde.org wrote: And I'm not sure there should be such a thing. Hm. You don't agree that a user experience like Sorry, missing X to do Y. Would you like to get X now for that? is better than one à la Na, no way to do Y.? Yes. since we can't assume the user has the right to install to the system directory, We can't assume for all, but in many installations the user does. Like the ususal private computer. For administrated systems, there could be a substitute which instead of allowing to install rather aids the user to file a request to the admin, for convenience and getting things done. and we shouldn't set up a complete development environment for him. I was thinking of interfacing to the normal packaging system of the system. He, something like DrKonqi installing the debug info packages on request. So something like that is existing already, just needs to be generalized perhaps. Cheers Friedrich openSUSE's version of KDE has something like this as well. It might be worth seeing how they do it. -Todd
