[zypp-devel] upgrade - removing unmaintained packages?
Hi all, zypp::UpgradeOptions() had 'delete_unmaintained' flag for removing unmaintained packages. But it's gone now. Why? How can we remove unmaintained packages now? The reason is: "gcc42 is explicitly not obsoleted, but only people that explicitly want to keep it should be able to do so" and "and any kind of package obsolete would do hard erase it" Coolo suggested adding a fixed list ("gcc42"...) somewhere into yast (probably into control.xml file). But maintaining a fixed list is wrong solution IMO... Should I implement the behavior in pkg-bindings level or is it possible to put it back to libzypp? What did the option do exactly? Thanks in advance Lada -- 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: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Ladislav Slezak schrieb:
Hi all,
zypp::UpgradeOptions() had 'delete_unmaintained' flag for removing unmaintained packages. But it's gone now. Why? How can we remove unmaintained packages now?
We have had this discussion on zypp-devel: http://lists.opensuse.org/zypp-devel/2008-02/msg00138.html and come to the conclusion to remove this flag.
The reason is: "gcc42 is explicitly not obsoleted, but only people that explicitly want to keep it should be able to do so" and "and any kind of package obsolete would do hard erase it"
Coolo suggested adding a fixed list ("gcc42"...) somewhere into yast (probably into control.xml file). But maintaining a fixed list is wrong solution IMO...
That's the only way to solve this "problem". You do not want to delete ALL unmaintained packages but special packages only.
Should I implement the behavior in pkg-bindings level or is it possible to put it back to libzypp? What did the option do exactly?
It should be solved outside of libzypp by setting delete request for each solvable. The current bahaviour of libzypp is described in the thread above. Greetings Stefan -- ******************************************************************************* Stefan Schubert SUSE LINUX GmbH - Maxfeldstrasse 5 - D-90409 Nuernberg, Germany e-mail: schubi@suse.de ------------------------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Am Dienstag 29 April 2008 schrieb Stefan Schubert:
It should be solved outside of libzypp by setting delete request for each solvable. The current bahaviour of libzypp is described in the thread above.
Hi, Did something happen here? Greetings, Stephan -- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Stephan Kulow napsal(a):
Am Dienstag 29 April 2008 schrieb Stefan Schubert:
It should be solved outside of libzypp by setting delete request for each solvable. The current bahaviour of libzypp is described in the thread above.
Hi,
Did something happen here?
Not yet. I'll add problematicUpdateItems() result into pkg bindings (to the result of Pkg::PkgUpdateAll() function). The rest must be solved on the yast level IMO. Lukas? -- 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: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Am Dienstag 06 Mai 2008 schrieb Ladislav Slezak:
Stephan Kulow napsal(a):
Am Dienstag 29 April 2008 schrieb Stefan Schubert:
It should be solved outside of libzypp by setting delete request for each solvable. The current bahaviour of libzypp is described in the thread above.
Hi,
Did something happen here?
Not yet. I'll add problematicUpdateItems() result into pkg bindings (to the result of Pkg::PkgUpdateAll() function).
The rest must be solved on the yast level IMO. Lukas?
Hmm? The list of packages I'm talking about need to be erased _before_ UpdateAll. The solver job needs to look like // from control file: uninstall gcc42 uninstall liboldlib // kernel switch uninstall kernel-default install kernel-pae distupgrade Greetings, Stephan -- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Stephan Kulow wrote: [...]
Hmm? The list of packages I'm talking about need to be erased _before_ UpdateAll. The solver job needs to look like
// from control file: uninstall gcc42 uninstall liboldlib
// kernel switch uninstall kernel-default install kernel-pae distupgrade
OK, this is something for the update code. Pkg-bindings could provide some details about problematic packages if needed. Lukas? -- 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: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Ladislav Slezak napsal(a):
Stephan Kulow wrote: [...]
Hmm? The list of packages I'm talking about need to be erased _before_ UpdateAll. The solver job needs to look like
// from control file: uninstall gcc42 uninstall liboldlib
// kernel switch uninstall kernel-default install kernel-pae distupgrade
OK, this is something for the update code. Pkg-bindings could provide some details about problematic packages if needed. Lukas?
I still don't think this is a good solution. Maintaining a fixed list, hmm... What does zypper do with 'zypper dup'? Will it use the same control file? Lukas
Am Dienstag 06 Mai 2008 schrieb Lukas Ocilka:
I still don't think this is a good solution. Maintaining a fixed list, hmm... That's ok. But you seem unable to provide an alternative too. And trust me, many people thought about this problem without being able to provide an alternative.
And the list of packages _is_ fixed - because what makes these packages different to other packages is that we _know_ they can not be replaced, but that the user has to be given a choice on keeping them.
What does zypper do with 'zypper dup'? Will it use the same control file?
People using zypper will not get that feature, so what? They don't get buttons either. Greetings, Stephan -- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
participants (4)
-
Ladislav Slezak -
Lukas Ocilka -
Stefan Schubert -
Stephan Kulow