[yast-devel] Package-Bindings
Greetings all, I require the following functions in yast2 package bindings to fix bugs. - Update package if and only if newer version available - Install package from a specific repository I don't believe either exists as I can't see anything appropriate from browsing the source. If either does exist please enlighten me, or I will file enhancement requests. Many thanks -- Benjamin Weber -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Benji Weber napsal(a):
Greetings all,
I require the following functions in yast2 package bindings to fix bugs.
- Update package if and only if newer version available
This doesn't seem to be problem of Pkg-bindings but libzypp. Libzypp automagically updates already installed packages even in the very same version.
- Install package from a specific repository
I don't believe either exists as I can't see anything appropriate from browsing the source. If either does exist please enlighten me, or I will file enhancement requests.
Hmm, not yet, you can select a specific version but repository is up to libzypp (probably during Commit). Lukas
- Update package if and only if newer version available
This doesn't seem to be problem of Pkg-bindings but libzypp. Libzypp automagically updates already installed packages even in the very same version.
I don't think it is a problem of libzypp as such, since package selectors (both, possibly all three?) already offer this functionality - update list of packages if and only if newer version is available. In a loop over all packages in current list, it's done like this: if ( slbPtr->status() == S_KeepInstalled && slbPtr->hasCandidateObj() ) { if ( slbPtr->installedObj()->edition() < slbPtr->candidateObj()->edition() ) ok = statusStrategy->keyToStatus( '>', slbPtr, objPtr, newStatus ); } Translated into normal speech: - If the package is currently installed and some candidate object exists *), compare installed and available version - if available version is greater, mark the package for update - else do nothing (*) the existence of candidate obj. exists does not necessarily mean that candidate has also greater version number (?), hence the second check It's not probably done in a best possible way ;-) (zypp guys could maybe provide us with better algorithm), but it works. So I believe similar algorithm could be incorporated into Pkg-bindings as well B. -- \\\\\ Katarina Machalkova \\\\\\\__o YaST developer __\\\\\\\'/_ & hedgehog painter
* Katarina Machalkova <kmachalkova@suse.cz> [Mar 19. 2008 14:28]:
In a loop over all packages in current list, it's done like this:
if ( slbPtr->status() == S_KeepInstalled && slbPtr->hasCandidateObj() ) { if ( slbPtr->installedObj()->edition() < slbPtr->candidateObj()->edition() ) ok = statusStrategy->keyToStatus( '>', slbPtr, objPtr, newStatus ); }
Be aware that 'newer edition available' is *not* the correct criterium for update in the future. The selection of packagages eligible for update is a (sat-)solver function, taking solver policies and conflict resolution into account.
It's not probably done in a best possible way ;-) (zypp guys could maybe provide us with better algorithm), but it works.
Zypp guys will (have to) provide an API for this. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Wednesday 19 March 2008 15:46, Klaus Kaempf wrote:
Be aware that 'newer edition available' is *not* the correct criterium for update in the future.
It never was. That's just a UI shortcut for "get me the newest version of all the packages I have installed". It never was and it never meant to be a substitute for system update.
The selection of packagages eligible for update is a (sat-)solver function, taking solver policies and conflict resolution into account.
Sure. But that's the system update. That's different. CU -- Stefan Hundhammer <sh@suse.de> Penguin by conviction. YaST2 Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Nürnberg, Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
* Stefan Hundhammer <sh@suse.de> [Mar 19. 2008 16:11]:
The selection of packagages eligible for update is a (sat-)solver function, taking solver policies and conflict resolution into account.
Sure. But that's the system update. That's different.
I am talking about 'install available updates to the packages I have installed'. Blindly grabbing (or schowing) all newer versions has a high probability of failure. Just think of kernel vs. driver. A kernel update might break an installed driver and a newer driver might not match my kernel. The sat-solver algorithm ensures that such conflicts are properly resolved. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
>>> On 3/19/2008 at 17:26, Klaus Kaempf <kkaempf@suse.de> wrote: > * Stefan Hundhammer <sh@suse.de> [Mar 19. 2008 16:11]: >> >> > The selection of packagages eligible for update is a (sat-)solver >> > function, taking solver policies and conflict resolution into account. >> >> Sure. But that's the system update. That's different. > > I am talking about 'install available updates to the packages I have > installed'. Blindly grabbing (or schowing) all newer versions has a high > probability of failure. Just think of kernel vs. driver. A kernel update > might break an installed driver and a newer driver might not match my > kernel. > > The sat-solver algorithm ensures that such conflicts are properly > resolved. The way yast and also zypper up -t package) work in this case are imho the way I as a user would expect it: I select: update those packages (I can select between the ones in list or all) and it then performs a dependency check. Additional requires are automatically included and in case something else happens, like a driver rpm not being compatible to my new kernel, I get a dependency conflict. This is exactly what I as a user expect to happen. of course Yast, having a nice interface, offers me more details solutions than I could possibly wish for in zypper. Dominique -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Be aware that 'newer edition available' is *not* the correct criterium for update in the future. The selection of packagages eligible for update is a (sat-)solver function, taking solver policies and conflict resolution into account.
But what would you, as the user (not sat-solver developer) expect, if you saw an option saying 'Update all packages in this list, if newer version is available' ? Wouldn't you want exactly that - mark packages for which a newer version appeared on configured repositories in the meantime, as the candidates for update? Of course, solver might not respect your decision ("Hey, I won't update this package for you"), just as it not always respects your decision if you mark package for update manually. frozenB. -- \\\\\ Katarina Machalkova \\\\\\\__o YaST developer __\\\\\\\'/_ & hedgehog painter
Katarina Machalkova napsal(a):
Be aware that 'newer edition available' is *not* the correct criterium for update in the future. The selection of packagages eligible for update is a (sat-)solver function, taking solver policies and conflict resolution into account.
But what would you, as the user (not sat-solver developer) expect, if you saw an option saying 'Update all packages in this list, if newer version is available' ? Wouldn't you want exactly that - mark packages for which a newer version appeared on configured repositories in the meantime, as the candidates for update?
Of course, solver might not respect your decision ("Hey, I won't update this package for you"), just as it not always respects your decision if you mark package for update manually.
Honestly, our users wanted such feature from our package management tools. The way they do it is exactly the way our users want it. After that, solver is called to check whether these 'update-to-newest-version' is proceeded. If solver doesn't find a solution for some packages, it reports such issues to user. That's correct. Moreover, this doesn't belong only to libzypp as user might just want to update only 'currently listed' packages (I want to upgrade only *yast2* packages if newer are available, plus their dependencies, of course). L.
* Katarina Machalkova <kmachalkova@suse.cz> [Mar 19. 2008 16:12]:
But what would you, as the user (not sat-solver developer) expect, if you saw an option saying 'Update all packages in this list, if newer version is available' ? Wouldn't you want exactly that - mark packages for which a newer version appeared on configured repositories in the meantime, as the candidates for update?
Actually, no. The distinction is between available and installable updates. I might be interested in (all) available updates but those actually installable are of much greater value. And whats a normal desktop user (keep in mind, with PackageKit you don't need to be root for updating your system) supposed to do with update conflicts ? I don't think she's able to decide between updating foo or bar. The solver, together with the policies defined by the admin, is the right place for such decisions. Again, I'm talking about the default case. This doesn't exclude an 'show all available updates' mode in the frontend tools. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Wouldn't you want exactly that - mark packages for which a newer version appeared on configured repositories in the meantime, as the candidates for update?
Actually, no.
The distinction is between available and installable updates.
I might be interested in (all) available updates but those actually installable are of much greater value.
I see your point. Anyway, I don't think it is possible (taking only 'static' data, not running the solver) to tell in advance whether the package that has newer version available, is also 'updatable' i.e. if this newer version is installable at the end. But users just want to see which package has newer version available (and which is, at least theoretically, 'updatable'). And they even want to be able to distinguish between them visually, using e.g. different color or a visual mark. I recall seeing several (usability related) bugs on this.
I don't think she's able to decide between updating foo or bar. The solver, together with the policies defined by the admin, is the right place for such decisions.
Please note that in UI, marking package for update does not necessarily mean that this package will be unconditionally updated at the end and the dependencies get all *cobe*d up because of it. It is only the means how the user tells the solver 'Hey there, I want you to update this package for me'. But at the end, it is the solver and its policies, who is the highest authority there. The one, who performs dependency check and who might refuse to respect user's decision and not to update particular pack, even if user wanted it to. frozenB. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
* Katarina Machalkova <kmachalkova@suse.cz> [Mar 19. 2008 23:08]:
Wouldn't you want exactly that - mark packages for which a newer version appeared on configured repositories in the meantime, as the candidates for update?
Actually, no.
The distinction is between available and installable updates.
I might be interested in (all) available updates but those actually installable are of much greater value.
I see your point. Anyway, I don't think it is possible (taking only 'static' data, not running the solver) to tell in advance whether the package that has newer version available, is also 'updatable' i.e. if this newer version is installable at the end.
Without running the solver, I agree.
But users just want to see which package has newer version available (and which is, at least theoretically, 'updatable'). And they even want to be able to distinguish between them visually, using e.g. different color or a visual mark. I recall seeing several (usability related) bugs on this.
Also agreed. I do not want to prevent this mode, it just shouldn't be the default.
I don't think she's able to decide between updating foo or bar. The solver, together with the policies defined by the admin, is the right place for such decisions.
Please note that in UI, marking package for update does not necessarily mean that this package will be unconditionally updated at the end and the dependencies get all *cobe*d up because of it.
Of course not, the solver will prevent this. But the feedback from the solver will be messy ;-)
It is only the means how the user tells the solver 'Hey there, I want you to update this package for me'. But at the end, it is the solver and its policies, who is the highest authority there. The one, who performs dependency check and who might refuse to respect user's decision and not to update particular pack, even if user wanted it to.
Right. By default, the solver should (and can) assist the user in selecting the right packages to update. Klaus -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Wed, Mar 19, Katarina Machalkova wrote:
It is only the means how the user tells the solver 'Hey there, I want you to update this package for me'. But at the end, it is the solver and its policies, who is the highest authority there. The one, who performs dependency check and who might refuse to respect user's decision and not to update particular pack, even if user wanted it to.
I would not put it that way. The solver does not refuse to respect user's decision. You can't ask someone to make a decision and then complain that it's not what you had decided. ;) In contrary, the solver policies define what the solver is alowed to decide automatically. And the slover respects this. If you ask the solver to update a package, the solver stops at it's boundaries. If he did not choose the package you would have chosen then because it is not installable due to dependency problems or the policies do not allow to select it. If the result does not match the expectation then one could think about changing the policies. E.g. allow automatic arch/vendor change. And finally you are always able to explicitly select the package you think is right. Challenging for the UI to explain all this to the user. -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres YaST Development ma@novell.com SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Michael Andres napsal(a):
I would not put it that way. The solver does not refuse to respect user's decision.
You can't ask someone to make a decision and then complain that it's not what you had decided. ;) ... Challenging for the UI to explain all this to the user.
Everything (these) users want is to have the latest packages installed on their systems. Use case: 1.) Show all packages from PacKman 2.) Click "All Packages" 3.) Select "Upgrade all (if possible, of course)" 4.) Check dependencies 5.) Solve conflicts (which might end up in some packages not being upgraded despite the fact there is a newer one available). 6.) Install/Upgrade packages That's all ~ and it's quite easy to present it to user. This is not for unexperienced users, of course. Solving conflicts might be nontrivial. L.
* Lukas Ocilka <lukas.ocilka@suse.cz> [Mar 20. 2008 11:14]:
Everything (these) users want is to have the latest packages installed on their systems.
Use case: 1.) Show all packages from PacKman 2.) Click "All Packages" 3.) Select "Upgrade all (if possible, of course)"
Now what's "if possible, of course" supposed to mean ? The point is, that the sat-solver provides just this functionality, 'compute all possible updates'. The result is 'solved', you won't get any dependency conflicts. This should be the default mode. Klaus -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Thursday 20 March 2008 14:05, Klaus Kaempf wrote:
3.) Select "Upgrade all (if possible, of course)"
Now what's "if possible, of course" supposed to mean ?
The point is, that the sat-solver provides just this functionality, 'compute all possible updates'. The result is 'solved', you won't get any dependency conflicts.
This should be the default mode.
This discussion is becoming more and more abstract. It might help to simply try using it rather than speculating about what it might or might not do. The UI functionality this is (now) all about is not the regular system update. It never meant to be anything like that. It's just a shortcut to save the user from repeatedly setting individual packages to "update". The typical use case is something like this: You look at a list with packages you are interested in. Say, all YaST packages, or all KDE packages. You might have used the "Search" filter view. Then you realize that there are newer packages. You want to update all your YaST or KDE packages. You use the context menu and select "All in this list -> update, if newer version available" Note: It doesn't say _anywhere_ that it will update to the most recent version. This discussion is moot. It simply sets the status to "update" - whatever the lib back-end does then. All the UI algorithm does is to check if a package selectable has a newer candidate. If it has, the status of this selectable is set to "update". This is the same as the user manually going through the list and setting all packages manually to "update" that have a newer candidate (i.e., those that were displayed in blue font color in the old package selector). Please note that there are list actions like this for all other possible selectable states ("Install", "Keep", "Delete", "Taboo", "Protected", "Don't install"). And there is also "Update unconditionally" which simply sets each package to "update", no matter if there is something to update to. Since this doesn't make sense in most use cases, we introduced that "update, if newer version is available". And of course there is the usual solver run afterwards if "auto check" is enabled or when the user hits "check" or when the user is about to leave the package selector with "accept". Business as usual. I really don't understand what this discussion is all about. CU -- Stefan Hundhammer <sh@suse.de> Penguin by conviction. YaST2 Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Nürnberg, Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
* Stefan Hundhammer <sh@suse.de> [Mar 20. 2008 14:42]:
Note: It doesn't say _anywhere_ that it will update to the most recent version. This discussion is moot. It simply sets the status to "update" - whatever the lib back-end does then.
Good, then we're in agreement.
All the UI algorithm does is to check if a package selectable has a newer candidate.
See, thats exactly the point. The UI _must not_ make the 'is newer' decision. The underlying library (talking to the solver) is the only authorative source of this decision. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Thursday 20 March 2008 15:44, Klaus Kaempf wrote:
All the UI algorithm does is to check if a package selectable has a newer candidate.
See, thats exactly the point. The UI _must not_ make the 'is newer' decision. The underlying library (talking to the solver) is the only authorative source of this decision.
Give me a function that returns this information, and I will gladly use it. ;-) CU -- Stefan Hundhammer <sh@suse.de> Penguin by conviction. YaST2 Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Nürnberg, Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
* Stefan Hundhammer <sh@suse.de> [Mar 20. 2008 16:26]:
On Thursday 20 March 2008 15:44, Klaus Kaempf wrote:
All the UI algorithm does is to check if a package selectable has a newer candidate.
See, thats exactly the point. The UI _must not_ make the 'is newer' decision. The underlying library (talking to the solver) is the only authorative source of this decision.
Give me a function that returns this information, and I will gladly use it. ;-)
Now we're in total agreement. Thank you. Yes, this functionality will be provided. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Dňa Thursday 20 March 2008 08:44:32 Klaus Kaempf ste napísal:
* Stefan Hundhammer <sh@suse.de> [Mar 20. 2008 14:42]:
Note: It doesn't say _anywhere_ that it will update to the most recent version. This discussion is moot. It simply sets the status to "update" - whatever the lib back-end does then.
Good, then we're in agreement.
All the UI algorithm does is to check if a package selectable has a newer candidate.
See, thats exactly the point. The UI _must not_ make the 'is newer' decision. The underlying library (talking to the solver) is the only authorative source of this decision.
I think this is something we need input from users. The issue is that your approach will make sure users will get smoothies user experience, but not possibly not all packages updated, while all other tools provide the more rough functionality, that gives users direct feedback that this particular package cannot be updated and why (dependency conflict). For openSUSE, it might be quite possible that the way other tools work is the one our users expect. Stano -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Thu, Mar 20, Klaus Kaempf wrote:
* Lukas Ocilka <lukas.ocilka@suse.cz> [Mar 20. 2008 11:14]:
Everything (these) users want is to have the latest packages installed on their systems.
Use case: 1.) Show all packages from PacKman 2.) Click "All Packages" 3.) Select "Upgrade all (if possible, of course)"
Now what's "if possible, of course" supposed to mean ?
The point is, that the sat-solver provides just this functionality, 'compute all possible updates'. The result is 'solved', you won't get any dependency conflicts.
Sat-solver also provides SOLVER_INSTALL_SOLVABLE_UPDATE to request the update of one solvable (within the limits of the policies). I'm thinking about using this to implement Solvable::freshen(). -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres YaST Development ma@novell.com SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Michael Andres napsal(a):
On Thu, Mar 20, Klaus Kaempf wrote:
* Lukas Ocilka <lukas.ocilka@suse.cz> [Mar 20. 2008 11:14]:
Everything (these) users want is to have the latest packages installed on their systems.
Use case: 1.) Show all packages from PacKman 2.) Click "All Packages" 3.) Select "Upgrade all (if possible, of course)" Now what's "if possible, of course" supposed to mean ?
The point is, that the sat-solver provides just this functionality, 'compute all possible updates'. The result is 'solved', you won't get any dependency conflicts.
Sat-solver also provides SOLVER_INSTALL_SOLVABLE_UPDATE to request the update of one solvable (within the limits of the policies). I'm thinking about using this to implement Solvable::freshen().
I'm sorry, without any offense, what does this mean in human speech? Thx Lukas
On Thu, Mar 20, Lukas Ocilka wrote:
The point is, that the sat-solver provides just this functionality, 'compute all possible updates'. The result is 'solved', you won't get any dependency conflicts.
Sat-solver also provides SOLVER_INSTALL_SOLVABLE_UPDATE to request the update of one solvable (within the limits of the policies). I'm thinking about using this to implement Solvable::freshen().
I'm sorry, without any offense, what does this mean in human speech?
I'm sorry. I missread 'compute all possible updates'. In the beginning Sat-solver was just able to 'compute ALL possible updates': a complete distribution update. Now there is a s well a request to compute the update for one individual package, this is what Solvable::freshen() should do. But Klaus meant 'compute all POSSIBLE updates': the solver won't return some solution that does not work. In that context my comment does not make much sense. -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres YaST Development ma@novell.com SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
* Michael Andres <ma@suse.de> [Mar 20. 2008 19:32]:
In the beginning Sat-solver was just able to 'compute ALL possible updates': a complete distribution update.
Now there is a s well a request to compute the update for one individual package, this is what Solvable::freshen() should do.
Actually, I believe that we need to cover the whole scale, from a single package to all packages. Stefan already mentioned it, the UI currently offers 'update all in this list' - updating just an arbitrary set of packages. This makes a lot of sense in the context of 'just updates from this repo' or 'just updates from this vendor'. So (probably post-openSUSE 11.0) we should think about a API to define (resp. restrict to) a set of packages. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Qui, 2008-03-20 às 19:41 +0100, Klaus Kaempf escreveu:
Stefan already mentioned it, the UI currently offers 'update all in this list' - updating just an arbitrary set of packages. This makes a lot of sense in the context of 'just updates from this repo' or 'just updates from this vendor'.
So (probably post-openSUSE 11.0) we should think about a API to define (resp. restrict to) a set of packages.
Yeah, in yast-gtk we use this container to pass selected packages around, that provides an interface for such properties and actions. Its like 20 lines of code on top of our Zypp wrapper. You guys should just focus in simplifying the zypp API into a nice set of primitives and let your users adapt them to their needs. And try to make things modular; like having live pools, so that different parts of the interface can keep track of package changes without much overhead. Use integers or plain pointers as references, don't force us into bridging your boost pointers to store them in C libraries. And stop condensing the syntax into single lines of excruciating, indecipherable code. Use your smarts to design things simply and flexible. Cheers, Ricardo -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Ricardo Cruz napsal(a):
Qui, 2008-03-20 às 19:41 +0100, Klaus Kaempf escreveu:
Stefan already mentioned it, the UI currently offers 'update all in this list' - updating just an arbitrary set of packages. This makes a lot of sense in the context of 'just updates from this repo' or 'just updates from this vendor'.
So (probably post-openSUSE 11.0) we should think about a API to define (resp. restrict to) a set of packages.
Yeah, in yast-gtk we use this container to pass selected packages around, that provides an interface for such properties and actions. Its like 20 lines of code on top of our Zypp wrapper.
You guys should just focus in simplifying the zypp API into a nice set of primitives and let your users adapt them to their needs. And try to make things modular; like having live pools, so that different parts of the interface can keep track of package changes without much overhead. Use integers or plain pointers as references, don't force us into bridging your boost pointers to store them in C libraries. And stop condensing the syntax into single lines of excruciating, indecipherable code. Use your smarts to design things simply and flexible.
Maybe libzypp should stay more low-level and such high-level API could be created in Libzypp Application Layer. That IMO seems to be the right place. http://en.opensuse.org/Libzypp/Application_Layer/API_Proposal (at least the functionality to upgrade selected, from repo, from vendor... packages). L.
Sex, 2008-03-21 às 10:36 +0100, Lukas Ocilka escreveu:
Ricardo Cruz napsal(a):
Qui, 2008-03-20 às 19:41 +0100, Klaus Kaempf escreveu:
Stefan already mentioned it, the UI currently offers 'update all in this list' - updating just an arbitrary set of packages. This makes a lot of sense in the context of 'just updates from this repo' or 'just updates from this vendor'.
So (probably post-openSUSE 11.0) we should think about a API to define (resp. restrict to) a set of packages.
[my comment]
Maybe libzypp should stay more low-level and such high-level API could be created in Libzypp Application Layer. That IMO seems to be the right place.
Sure, I was replying to the API comment. That is, the Application Programmers Interface. Or Application Layer, as you kids call it. ;) Seriously, if by low-level you mean all those files that seem to have only internal garbage that nobody should care about, I agree those things should not be published as currently they are. You could have some constructs available like those. Preferably, it would be a generic interface that would be implemented for the pools too. But if you KISS the API, this would not be an issue. As it was stated, it sounded like a patch trying to block the hemorrhage that is libzypp. :/ Some cool stuff that we actually need is to have a proper channel to get the package dependencies (not the raw strings), so that we can draw some nice graphs, and let the user jump around.
http://en.opensuse.org/Libzypp/Application_Layer/API_Proposal
Okay, this is my proposal: http://svn.opensuse.org/svn/yast/trunk/gtk/src/yzyppwrapper.h A lot of it was done as I needed, so it could be beautified (and stuff like categories should be abstracted as some package ancestor type), but its simple and serves our interface fine. e.g. If you'd like to populate your Table widget: Ypp::QueryPool::Query *query = new Ypp::QueryPool::Query(); query->addType (Ypp::Package::PACKAGE_TYPE); query->setIsInstalled (false); Ypp::QueryPool *pool = new Ypp::QueryPool (query); for (Ypp::Pool::Iter it = pool->getFirst(); it; it = pool->getNext (it)) { Ypp::Package *pkg = pool->get (it); table->addRow (pkg->name()); } And you can setup an object to reflect pool changes in your table: struct LiveTable : Ypp::Pool::Listener { LiveTable (Pool *pool, Table *table) : ... { pool->setListener (this); } ~LiveTable() { delete m_pool; } virtual void entryChanged (Ypp::Pool::Iter iter, Package *package) { m_table->edit (toRow (iter), package->name()); } virtual void entryInserted (Ypp::Pool::Iter iter, Package *package) { m_table->add (toRow (iter), package->name()); } virtual void entryDeleted (Ypp::Pool::Iter iter, Package *package) { m_table->remove (toRow (iter)); } int toRow (Ypp::Pool::Iter iter) { return m_pool->toPath (iter).first(); } }; If possible, its better to extend the Table widget of the GUI toolkit to avoid the overhead of copying the data around without the rows being visible, but the same API is fine for that. With regard to the abstract attributes in your proposal -- I'm not sure if that really is worth the trouble. It means more work for Zypp developers and API users just to make it a tad easier to extend for new attributes. Besides, you may want to use more data types than strings and integers; like paths for the categories. So, some attributes may actually be more work to extend, as you need to add more hooks to the data abstractor. Either way, more important and tricky is to get nice ways to go through the relations between packages-patterns and packages-categories. It should be possible to navigate through a tree of those with the Pool object. I never got to abstract those; just implemented Pools for those purposes. Cheers, Ricardo -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Wed, Mar 19, 2008 at 06:52:51PM +0100, Klaus Kaempf wrote:
* Katarina Machalkova <kmachalkova@suse.cz> [Mar 19. 2008 16:12]:
But what would you, as the user (not sat-solver developer) expect, if you saw an option saying 'Update all packages in this list, if newer version is available' ? Wouldn't you want exactly that - mark packages for which a newer version appeared on configured repositories in the meantime, as the candidates for update?
Actually, no.
The distinction is between available and installable updates.
I might be interested in (all) available updates but those actually installable are of much greater value.
And whats a normal desktop user (keep in mind, with PackageKit you don't need to be root for updating your system) supposed to do with update conflicts ? I don't think she's able to decide between updating foo or bar. The solver, together with the policies defined by the admin, is the right place for such decisions.
There really needs to be a "run full blown YAST2 Online Update (after su)" option in those PackageKit updaters. Ciao, Marcus -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
* Marcus Meissner <meissner@suse.de> [Mar 20. 2008 00:19]:
There really needs to be a "run full blown YAST2 Online Update (after su)" option in those PackageKit updaters.
And whats that going to provide above "install all installable updates" ? If you're refering to a "show all available updates and let me decide" mode, I fully agree. Klaus -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Thu, Mar 20, 2008 at 12:59:11AM +0100, Klaus Kaempf wrote:
* Marcus Meissner <meissner@suse.de> [Mar 20. 2008 00:19]:
There really needs to be a "run full blown YAST2 Online Update (after su)" option in those PackageKit updaters.
And whats that going to provide above "install all installable updates" ?
If you're refering to a "show all available updates and let me decide" mode, I fully agree.
The issue is more "Handle conflicts in a good way", yes. Ciao, Marcus -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Lukas Ocilka napsal(a):
Benji Weber napsal(a):
Greetings all,
I require the following functions in yast2 package bindings to fix bugs.
- Update package if and only if newer version available
This doesn't seem to be problem of Pkg-bindings but libzypp. Libzypp automagically updates already installed packages even in the very same version.
What parameters would you need here? Just the package name or exact version, from any or from a specified repository...?
- Install package from a specific repository
I don't believe either exists as I can't see anything appropriate from browsing the source. If either does exist please enlighten me, or I will file enhancement requests.
Hmm, not yet, you can select a specific version but repository is up to libzypp (probably during Commit).
That should be possible in libzypp, but it seems to be broken now (even if I used Repository filter in the qt packager widget libzypp installed the package from another repository, the bug might be in libzypp or in qt-pkg). Pkg bindings have function Pkg::ResolvableInstallArchVersion( string name, symbol kind, string arch, string vers ) so it's possible to specify kind, version and arch, but not the repository. I can create a new binding for that... What parameters do you need in addition to package name? What about Pkg::ResolvableInstallRepo( string name, symbol kind, integer repo )? -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On 19/03/2008, Ladislav Slezak <lslezak@suse.cz> wrote:
Pkg bindings have function
Pkg::ResolvableInstallArchVersion( string name, symbol kind, string arch, string vers )
Yes, I had found this one :)
so it's possible to specify kind, version and arch, but not the repository. I can create a new binding for that... What parameters do you need in addition to package name?
What about Pkg::ResolvableInstallRepo( string name, symbol kind, integer repo )?
That would be perfect. -- Benjamin Weber -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Hi Benji, Benji Weber wrote:
On 19/03/2008, Ladislav Slezak <lslezak@suse.cz> wrote:
What about Pkg::ResolvableInstallRepo( string name, symbol kind, integer repo )?
That would be perfect.
OK, added in yast2-pkg-bindings-2.16.21. Ladislav -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
participants (11)
-
Benji Weber -
Dominique Leuenberger -
Katarina Machalkova -
Klaus Kaempf -
Ladislav Slezak -
Lukas Ocilka -
Marcus Meissner -
Michael Andres -
Ricardo Cruz -
Stanislav Visnovsky -
Stefan Hundhammer