Guillaume Rousse a écrit :
Le 01/08/2012 09:31, Guillaume Rousse a écrit :
Le 01/08/2012 08:46, Thierry Vignaud a écrit :
On 1 August 2012 05:29, fwang <[email protected]> wrote:
fwang <fwang> 3-21.mga3:
+ Revision: 277136
- obsolete db5.2 in favour of db5.3
# urpmi --auto-select --keep -vv --debug
(...)
installed libreoffice-core-3.6.0.1-1.mga3.x86_64 is conflicting
because of unsatisfied libdb-5.2.so()(64bit)
unselecting task-obsolete-3-21.mga3.noarch
A requested package cannot be installed:
task-obsolete-3-21.mga3.noarch (in order to keep
libreoffice-core-3.6.0.1-1.mga3.x86_64)
Continue installation anyway? (Y/n)
Whoever had the brilliant idea of forcing package uninstallation just
because "they are not supported anymore" deserve a good spanking...
Especially when applied to libraries, whereas shipping them in specific
versioned subpackage 'libfication' was meant precisely to avoid this
issue.
Morevoer, it's quite ridiculous to focus on removing obsoleted package
from end users machines, without first cleaning our own
infrastructure: db5.2 is still present in the subversion repository,
for instance...
So, removing a package from the distribution should imply:
1) removing it from the subversion repository
2) removing it from the master package tree (adding obsoletes tag in
any package just for this is overkill)
3) eventually removing it from end user machines, provided this last
step bring some added value (which is still unproven)
+1
This last point reminds me of the obsoletes of openoffice put in the
libreoffice spec, when there was no real conflicts and there were some
differences. So a regression in libreoffice required me to install
upstream libreoffice so I could install openoffice alongside, to work
around the regressions when I needed to.
So definitely no added value.
These obsoletes are still there.
--
André