[oclug] rpm and obsoleted packages

[Gilles J. Seguin]

"Michael P. Soulier" wrote:
> 
> On 12/06/03 Gilles J. Seguin did speaketh:
> 
> > > 1. Install package A.
> > > 2. Install package B which obsoletes A.
> > > 3. A should be removed during B's installation.
> > > 4. Install B again, and note that rpm does not complain.
> >
> > test case rejected
> 
>     *sigh* Let me demonstrate why I'm right and you're wrong. :)
> 
> [root at sme1-60 root]# ls
> test-0.0.1.1-01.noarch.rpm  testmore-0.0.1.1-01.noarch.rpm
> [root at sme1-60 root]# rpm -qp --obsoletes testmore-0.0.1.1-01.noarch.rpm
> test
> [root at sme1-60 root]# rpm -Uvh test-0.0.1.1-01.noarch.rpm
> Preparing...                ###########################################
> [100%]
> [root at sme1-60 root]# rpm -q test
> test-0.0.1.1-01
> [root at sme1-60 root]# rpm -Uvh testmore-0.0.1.1-01.noarch.rpm
> Preparing...                ###########################################
> [100%]
> [root at sme1-60 root]# rpm -q test
> package test is not installed
> 
>     So far so good. testmore obsoletes test, so test is removed when
> testmore is installed. Now for the bug.
> 
> [root at sme1-60 root]# rpm -q testmore
> testmore-0.0.1.1-01
> # rpm -Uvh test-0.0.1.1-01.noarch.rpm
> Preparing...     ########################################### [100%]
> [root at sme1-60 root]# rpm -q test testmore
> test-0.0.1.1-01
> testmore-0.0.1.1-01
> 
>     Voila. rpm permits both test and testmore to be installed, even
> though testmore obsoletes test.
> 
>     Looks like a bug to me.

I have mention that this query option is an option,
but not an option that we want to see in a distribution release.

I will be very unhappy.
Reasons being that your intern Quality Analysis Team,
that may be only you, are in trouble.
They must requalify all softwares affected by package removal.
Very bad for business.

The alternative/solution is to backport.

=====

If time and/or money is not an issue
or to allow an upgrade path from previous stable distribution release,
the --obsoletes option query is nice to have.

An example would be the coreutils package.
Installing this packages removed textutils, fileutils, sh-utils,
stat packages.

Trying to reinstall any of thoses removed packages will be impossible
because of files conflict.

=====

The system administrator do want to know when problem may occurs
for package that he want to install.

Solution is to used, (from documentation)
   The conflicts tag is the logical complement to the requires tag.
   The requires tag is used to specify what packages must be present
in order for the current package to operate properly. 
   The conflicts tag is used to specify what packages cannot be 
installed if the current package is to operate properly. 

In reality, such thing is not used.
Because flexible/different environment may require the utilization
of both packages.  In such case, we require something like
switchdesk, switchprinter, switchMailTransferAgent packages.