August 2009 - openSUSE Software Management

[softwaremgmt] Autoenable-feature for services
by J. Daniel Schmidt 18 Oct '10

18 Oct '10

Hi, I'd like to discuss a new feature for (NU) Services. A service can contain multiple repos and they may change over time. All these changes are automatically apllied to the system during a refresh of the service. But one thing is missing IMHO. All new repos always remain disabled and have to be enabled manually. In the registration process we therefore enable each repo one by one. The server has no way to tell the client what repos should be enabled in his opinion. And the client has no possibility to change the policy to always enable repos in services. I'd recommend to add a new property to the repo definition in the repoindex.xml: enable="1". Repos tagged like this should be enabled (of course only in the opinion of the server). When a service gets added on a client the service should get a new parameter: autoenable=<value> in its service file (zypper needs to support it). The value might be one of: all = automatically enable all repos that the server has remote = automatically enable all repos that are tagged with enable="1" none = no automatic enabling - default (if missing), to be backward compatible By this, the authority still remains on the client. The client can decide what policy he wants to use. And the change of the policy is per service, so changing the policy for one service does not change for all services. This would be a nice feature for services as you could add one service that you trust (maybe you administer it yourself) and then forget about it, as the repos will always adapt automatically. I had short conversations with Duncan MacVicar and Marcus Meissner about this topic today but now want to open it for a discussion. What do you think? Are there better ways to do this? Are there side-effects or security issues? Ciao, Daniel -- J. Daniel Schmidt <jdsn(a)suse.de> SUSE Linux Products GmbH Research & Development Maxfeldstr. 5 GF: Markus Rex, HRB 16746 (AG Nürnberg) D-90409 Nürnberg -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help(a)opensuse.org

2 2

[softwaremgmt] rypper - extension for managing multiple repositories via zypper
by Adam Spiers 16 Sep '09

16 Sep '09

Hi all, Such is the value of the openSUSE Build Service from my perspective that I now have over 40 repositories registered on my main SUSE machine! I found that zypper was slightly awkward for managing this number of repositories, so I found a few hours of spare time to knock up the following; hope it's of use to somebody. Patches welcome! http://adamspiers.org/computing/rypper Here is an extract from the documentation for those reading this offline on their Blackberries :-) =head1 NAME rypper - extension for managing multiple repositories via zypper =head1 SYNOPSIS # See complete usage documentation rypper --help # list all disabled repos rypper -d # list all enabled repos with autorefresh off rypper -e -R # list all repos which have anything to do with KDE rypper -x kde # list priority and URIs for all repos whose alias contains 'home:' rypper -a home: l -pu # enable autorefresh on all OpenSUSE Build Service repos rypper -u download.opensuse.org -R mr -r # remove all repos on external USB HDD mounted on /media/disk rypper -u /media/disk rr =head1 DESCRIPTION rypper is a wrapper around zypper for performing repository operations in batch. It allows selection of which repositories to operate on via a number of different repository selection specifiers. The zypper commands which can be wrapped are: removerepo, rr Remove specified repository. modifyrepo, mr Modify specified repository. refresh, ref Refresh all repositories. clean Clean local caches. Additionally, the zypper pseudo-command 'l' can be used to list matching repos. There are a number of options controlling the output format; run C<rypper --help> for details. If no zypper command is provided, it defaults to the 'l' pseudo-command, trying to intelligently choose which fields to display, e.g. omitting any which were included in the repo selection parameters. -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help(a)opensuse.org

2 2

[softwaremgmt] Software management status update using zypp:Head YaST:Head on 11.1
by Cristian Morales Vega 07 Aug '09

07 Aug '09

Some time ago I wrote about the problems in the software management stack. At that time zypper was a good tool, but the GUI apps did too much by themself without asking libzypp. Now I have added the zypp:Head and YaST:Head repos to my openSUSE 11.1, and that's what I see (looking at the QT version of sw_single, no idea about GTK): The good: 1- The YaST search now is a lot faster than in default 11.1. 2- As explained in http://jniq.blogspot.com/ the zypper interface now it's a lot better. The bad: 1- It's my understanding that sw_single still hasn't an equivalent to "zypper update". Neither Package->All Packages->Update if newer version available/Update unconditionally do the same. No sure if for single package installs the dependency resolution now is equivalent to zypper. 2- The vendor thing... OK, I don't see where the problem is, but it seems users have a problem when YaST ask them if it's ok to do a vendor change. They just see a "dependency conflict" and get scared. I would say that dialog could indeed get an update: 2.1- The classic situation gives three options: "vendor change", "do not install" or "ignore deps". Neither of them selected by default. Since users report that they click "OK" and they don't see any change (normal, they selected to do nothing) I would suggest two alternatives a) Enable the first option by default. Is ZYpp really returning them in an order that makes sense? b) Disable the OK button until the user selects an option. 2.2- The vendor change option could be reported with a better layout I get: Conflic Resolution: <radiobutton> Following actions will be done: install <package> (with vendor change) <previous vendor> --> <new vendor> <number (of lines)> more... <radiobutton> do not install <package> <radiobutton> ignore some dependencies of <package> So 2.2.1- The first radiobutton is in "Following actions will be done" and should be in "install <package> (with vendor change)". That could be a problem because of my mix of 11.1 and Factory packages. But if isn't it is a bug. 2.2.2- "<previous vendor> --> <new vendor>" is easier to read if is in a single line, I don't see space problems. 2.2.3- "<number (of lines)> more..." isn't clear. The "number" is lines of text, packages or what? Only once you click you see it means lines of text, that I would say isn't the best option... number of (more) packages that need a vendor change would make more sense. 2.2.4- "ignore some dependencies" is too dangerous. I would hide it and only show it if the user has activated an "advanced" mode in YaST sw_single. 2.2.5- Since now we have only two option (vendor change or do not install) I would argue that all the dialog should be redone. I would argue that there should be two dialogs, one specific for vendor changes and another for "real" dependency resolution problems that require a decision from the user. The vendor change specific dialog would say something as: "The selected action requires to change some packages for versions provided by different vendors. If you subtitute an official package from openSUSE by one provided by a third party you will lose the support from openSUSE. If you continue these packages will be subtituted by others from different vendors: <packageA>: <old_vendorA> --> <new_vendorB> <packageB>: <old_vendorB> --> <new_vendorB>" An "OK" would be equivalent to the current first option. A "Cancel" would be equivalent to the current second option. If the user clicks on "Cancel" he will return to the main sw_single window and the package that triggered the vendor change will be unselected (now the package continues marked for installation, so the conflict dialog will show again at some point). I mean, if I mark libxine1-codecs for install I get the dialog asking for a vendor change of libxine1... if I click on "cancel" libxine1 isn't marked for installation but libxine1-codecs is keep marked. 2.3- An alternative option is to add another option to the main sw_single module: "Force resolution". It would be the same option available in zypper. If "Force resolution" is enabled YaST will not ask the user when there are multiple possibilities, it will select the options it thinks it's better automatically. zypper forces resolution by default for "install" and asks the user for "update". 3- The updater applet from default 11.1 can only update patches. It seems a problem in PackageKit, that only knows about a single update, not about patches/packages. IIRC it's already reported in bugzilla. No idea if it's already fixed in Factory and I don't see a package backported to 11.1. So... for what should I open a bug? The lack of a "zypper update" equivalent in sw_single is known since a lot ago. Any plans to fix it for 11.2? Since you have been working on the zypper interface, can I suppose you are already also working in the YaST interface to solve problems as the vendor change dialog I just explained? I would summarize the current situation as: "with the new zypper interface I don't need the GUI anymore, but if I would want to use it I couldn't.". Because the lack of "zypper update" for GUI apps is a really big problem if you want to use them. -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help(a)opensuse.org

2 2