[zypp-devel] ui::Selectable::theObj()
Shouldn't $subject return kernel-default-2.6.27-12.1.x86_64 given these are available in the pool? $ zypper search -s --match-exact kernel-default Loading repository data... Reading installed packages... S | Name | Type | Version | Arch | Repository --+----------------+------------+---------------+--------+---------------------------- i | kernel-default | package | 2.6.25.16-0.1 | x86_64 | Updates for 11.0 v | kernel-default | package | 2.6.25.11-0.1 | x86_64 | Updates for 11.0 v | kernel-default | package | 2.6.25.9-0.2 | x86_64 | Updates for 11.0 v | kernel-default | package | 2.6.25.16-0.1 | i586 | Updates for 11.0 v | kernel-default | package | 2.6.25.11-0.1 | i586 | Updates for 11.0 v | kernel-default | package | 2.6.25.9-0.2 | i586 | Updates for 11.0 v | kernel-default | package | 2.6.27-12.1 | x86_64 | openSUSE Factory (standard) v | kernel-default | package | 2.6.27-12.1 | i586 | openSUSE Factory (standard) v | kernel-default | package | 2.6.27-7.2 | i586 | iso | kernel-default | srcpackage | 2.6.25.16-0.1 | noarch | Updates for 11.0 | kernel-default | srcpackage | 2.6.27-7.2 | noarch | iso It returns 2.6.25.16-0.1 (the installed one) from SelectableImpl::defaultCandidate() -- cheers, jano -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Jano Kupec wrote:
Shouldn't $subject return kernel-default-2.6.27-12.1.x86_64 given these are available in the pool?
$ zypper search -s --match-exact kernel-default Loading repository data... Reading installed packages...
S | Name | Type | Version | Arch | Repository --+----------------+------------+---------------+--------+----------------------------
i | kernel-default | package | 2.6.25.16-0.1 | x86_64 | Updates for 11.0 v | kernel-default | package | 2.6.25.11-0.1 | x86_64 | Updates for 11.0 v | kernel-default | package | 2.6.25.9-0.2 | x86_64 | Updates for 11.0 v | kernel-default | package | 2.6.25.16-0.1 | i586 | Updates for 11.0 v | kernel-default | package | 2.6.25.11-0.1 | i586 | Updates for 11.0 v | kernel-default | package | 2.6.25.9-0.2 | i586 | Updates for 11.0 v | kernel-default | package | 2.6.27-12.1 | x86_64 | openSUSE Factory (standard) v | kernel-default | package | 2.6.27-12.1 | i586 | openSUSE Factory (standard) v | kernel-default | package | 2.6.27-7.2 | i586 | iso | kernel-default | srcpackage | 2.6.25.16-0.1 | noarch | Updates for 11.0 | kernel-default | srcpackage | 2.6.27-7.2 | noarch | iso
It returns 2.6.25.16-0.1 (the installed one) from SelectableImpl::defaultCandidate()
Additional notes: The selectable contains all thepackages from above. And i got it from a PoolQuery/SolvIterMixin: PoolQuery q; q.addKind(kind); q.addAttribute(sat::SolvAttr::name, str); q.setMatchGlob(); for_(s, q.selectableBegin(), q.selectableEnd()) {...} j. -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Friday 03 October 2008 15:44:26 Jano Kupec wrote:
Shouldn't $subject return kernel-default-2.6.27-12.1.x86_64 given these are available in the pool?
You can't tell with out looking at the repo priorities. This is the highest key. Also in case some candidate is selected to be installed. It will automatically become theObj. theObj is a ui hack. The ui uses it e.g. in the list views to display a summary. The ui does not care about which objects summary it is. It should be the 'most interesting one'. That's why it always picks a selected item. The one that will get installed is 'interesting'. -- 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: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Andres wrote:
On Friday 03 October 2008 15:44:26 Jano Kupec wrote:
Shouldn't $subject return kernel-default-2.6.27-12.1.x86_64 given these are available in the pool?
You can't tell with out looking at the repo priorities. This is the highest key.
There should be a method in Selectable that would select 'the best' object taking into account all the preferences the solver would use (the function could be even made available by the solver), with current policies. Such method could be used instead of curret defaultCandidate() in the candidateObj() method. And zypper would make use of such method a lot. Of course, the solver has the final word as to what will be finally installed, but the candidate returned by such method would be much better than the current semi-random one.
Also in case some candidate is selected to be installed. It will automatically become theObj.
theObj is a ui hack. The ui uses it e.g. in the list views to display a summary. The ui does not care about which objects summary it is. It should be the 'most interesting one'. That's why it always picks a selected item. The one that will get installed is 'interesting'.
OK, but in that case the description of the method was wrong and it fooled me to use the method in zypper. I fixed the description (Michael, pls check it) and will replace the remaining usages in zypper. What still puzzles me, though, is why theObj() returns different objects if i change repo priorities (like in bug #437854): ===================== $ zypper lr -p # │ Alias │ Name │ Enabled │ Refresh │ Priority ───┼─────────────┼─────────────────┼─────────┼─────────┼───────── 1 │ factory │ factory │ Yes │ No │ 99 10 │ zypp_svn │ ZYPP SVN Builds │ Yes │ No │ 90 $ zypper se --match-exact -s zypper S | Name | Type | Version | Arch | Repository - --+--------+------------+-------------+--------+----------------- v | zypper | package | 0.12.12-2.1 | x86_64 | ZYPP SVN Builds v | zypper | package | 0.12.12-1.5 | x86_64 | factory i | zypper | package | 0.12.12-1.4 | x86_64 | (System Packages) $ zypper info zypper Repository: ZYPP SVN Builds Name: zypper Version: 0.12.12-2.1 $ zypper mr -p 120 zypp_svn Repository 'zypp_svn' priority has been set to 120. $ zypper info zypper Repository: factory Name: zypper Version: 0.12.12-1.5 ====================== I can't see anything in the SelectableImpl code doing this. Is the list of available objects sorted in some way? Is it intentional, or it 'just happend'? - -- cheers, jano Ján Kupec YaST team - ---------------------------------------------------------(PGP)--- Key ID: 637EE901 Fingerprint: 93B9 C79B 2D20 51C3 800B E09B 8048 46A6 637E E901 - ----------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkkh7CUACgkQgEhGpmN+6QFVHACfUlMGjN7eJ46gJ8khxTAEAkBa gmAAn2XiuLcEFfFgaRXcKWZ0vTFlo1GD =dN/N -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Monday 17 November 2008 23:11:49 Jan Kupec wrote:
theObj is a ui hack. The ui uses it e.g. in the list views to display a summary. The ui does not care about which objects summary it is. It should be the 'most interesting one'. That's why it always picks a selected item. The one that will get installed is 'interesting'.
OK, but in that case the description of the method was wrong and it fooled me to use the method in zypper. I fixed the description (Michael, pls check it) and will replace the remaining usages in zypper.
+ /** + * Returns one of available objects, specifically either the user + * selected candidate or a default. + * + * Default is either the first available object which has the same arch + * as one of the installed objects, or the first available object + * (if none of available arch matches the arch of the installed objects), + * or empty. + * + * \return a PoolItem according to the describe criteria No, you should not try to describe implementation details in the description as they change (and the description is not correct anyway). The method returns the 'Best' or 'most interesting' among all available objects. One that is, or is likely to be, chosen for installation. Nothing else. + /** + * The object whose summary to show in the UIs. + * + * \return the \ref candidateObj(), if not empty, or the first of installed + * objects or an empty \ref PoolItem. + * \see candidateObj() It's not the 'object whose summary to show in the UIs'. Yes, UI does it that way, but but that does not mean it is OK. ;) The method returns you the candidate, or ,if no available objects exist, the last one installed.
What still puzzles me, though, is why theObj() returns different objects if i change repo priorities (like in bug #437854):
Of course, as the repo priority influences the what might get selected. The candidate (and also theObj) may change at any time. -- 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: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Andres wrote:
No, you should not try to describe implementation details in the description as they change (and the description is not correct anyway).
Well, i did not know how else to describe the method, after realizing what it actually does.
The method returns the 'Best' or 'most interesting' among all available objects. One that is, or is likely to be, chosen for installation. Nothing else.
But that is not true! It returns 'some', not 'the best' in any terms. 'The best' would mean the latest version, the best arch, the highest priority, etc... But currently it just select 'some' (well, the installed arch is considered).
What still puzzles me, though, is why theObj() returns different objects if i change repo priorities (like in bug #437854):
Of course, as the repo priority influences the what might get selected. The candidate (and also theObj) may change at any time.
I understand that, but where is the code doing this currently? - -- cheers, jano Ján Kupec YaST team - ---------------------------------------------------------(PGP)--- Key ID: 637EE901 Fingerprint: 93B9 C79B 2D20 51C3 800B E09B 8048 46A6 637E E901 - ----------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkkir6cACgkQgEhGpmN+6QHO5ACggaBwGx2vcjXpSe5fDhd9K8/v NV4AnjY/HTkj4xJuLyQzNmKY1iCTwJvN =WYfn -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Tuesday 18 November 2008 13:05:59 Jan Kupec wrote:
Michael Andres wrote:
The method returns the 'Best' or 'most interesting' among all available objects. One that is, or is likely to be, chosen for installation. Nothing else.
But that is not true! It returns 'some', not 'the best' in any terms. 'The best' would mean the latest version, the best arch, the highest priority, etc... But currently it just select 'some' (well, the installed arch is considered).
No, the set is ordered!
What still puzzles me, though, is why theObj() returns different objects if i change repo priorities (like in bug #437854):
Of course, as the repo priority influences the what might get selected. The candidate (and also theObj) may change at any time.
I understand that, but where is the code doing this currently?
zypp::ui::SelectableTraits struct AVOrder; // functor typedef std::set<PoolItem,AVOrder> AvailableItemSet; typedef AvailableItemSet::iterator available_iterator; typedef AvailableItemSet::const_iterator available_const_iterator; typedef AvailableItemSet::size_type available_size_type; -- 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: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Andres wrote:
On Tuesday 18 November 2008 13:05:59 Jan Kupec wrote:
Michael Andres wrote:
The method returns the 'Best' or 'most interesting' among all available objects. One that is, or is likely to be, chosen for installation. Nothing else. But that is not true! It returns 'some', not 'the best' in any terms. 'The best' would mean the latest version, the best arch, the highest priority, etc... But currently it just select 'some' (well, the installed arch is considered).
No, the set is ordered!
What still puzzles me, though, is why theObj() returns different objects if i change repo priorities (like in bug #437854): Of course, as the repo priority influences the what might get selected. The candidate (and also theObj) may change at any time. I understand that, but where is the code doing this currently?
zypp::ui::SelectableTraits
struct AVOrder; // functor
typedef std::set<PoolItem,AVOrder> AvailableItemSet;
typedef AvailableItemSet::iterator available_iterator; typedef AvailableItemSet::const_iterator available_const_iterator; typedef AvailableItemSet::size_type available_size_type;
Aaaah, that is the piece of info i was looking for :O) Thanx and sorry for the noise! So zypper _can_ use this after all. But there is still an issue due to which i originally started this thread. I'll follow up there. - -- cheers, jano Ján Kupec YaST team - ---------------------------------------------------------(PGP)--- Key ID: 637EE901 Fingerprint: 93B9 C79B 2D20 51C3 800B E09B 8048 46A6 637E E901 - ----------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkkiyysACgkQgEhGpmN+6QEazwCePXZtMzjXms/Az46XGhi2W3Ru 18QAn0W8AZleU87uTPGRhQeOmteBpav8 =mPri -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
participants (3)
-
Jan Kupec -
Jano Kupec
-
Michael Andres