n3npq at mac.com
Wed Aug 8 00:11:44 CEST 2007
On Aug 7, 2007, at 5:00 PM, Jakub Bogusz wrote:
>> All I ask is a a clear consensus on what is desired in rpm ;-)
> Currently we can't make a consensus ourselves ;)
You're not alone ...
> The problem is the meaning of Obsoletes - it used to have two meanings
> in PLD:
> - some package (A) became is obsolete and new package (B) replaces its
> functionality (clear: A disappears from distro, B becomes available
> with Obsoletes: A)
This is what I call "package renaming", and is the reason for Obsoletes:
to get depsolvers snarled up in discovering new and alternative names.
> - a set of packages provide the same functionality and we want at most
> only one of them to be installed (so every package Obsoletes the
> or - since rpm 4.0.x(?) - all packages have Provides:
> some-virtual-provide and Obsoletes: some-virtual-provide)
> (and now:
FWIW, other packages can be erased by, say, file path:
will erase all other printer daemons when installing a new printer
> - some people want to be able to install more than one package
> similar functionality, like HTTP or SMTP servers)
This is the "alternatives" problem. Why one would want 1-of-N behavior
always eluded me, reinstalling other rpm packages avoids the complexity.
> With first two there was no problem until some higher-level package
> managers (like yum) forced the first meaning (only) and started to
> randomly replace e.g. SMTP servers with the other one in each run.
> If you are willing to code something that helps, my proposal would
> be (of
> course after making consensus in PLD first) to implement some flags
> Obsoletes tag, e.g.:
> "Obsoletes(replacement):" (or "Replaces:"?) for mutually exclusive
I would use something other than a Obsoletes:. Hysterically, RH
package style tried to remove end-of-life software, so the packages
already contained an Obsoletes:. What has always been a pain is
discovering the Newer! Better! Bestest! package that replaces the old
These days so many packages have been renamed, that virtual Provides:
are quite common, so I'd use
with exactly the same semantic interpretation.
> "Obsoletes(hint):" ("suggested obsolete") for packages which don't
> physically conflict, but usually aren't installed together (e.g.
> SMTP servers, all configured to listen on the same port by default)
All dependencies are permitted (hint) qualifiers, including Provides:
Conflicts:, and Obsoletes:. The RPMSENSE_MISSINGOK underlying
semantic just means the rpmlib itself will not do anything special,
like quitting with an error, for those hinted dependencies.
Feel free to add your own semantic interpretation.
> and plain "Obsoletes:" tag would be left for obsolete packages only.
> For yum fans: such change in rpm alone probably won't solve anything
> with yum, as their maintainers are unlinkely to implement this
> (just like Suggests)...
>>> Also, you found a set of packages which are really mutually
>>> and installing more than one makes no sense: issue*. Just dropping
>>> Obsoletes makes an unresolved conflict in distribution (try poldek
>>> --verify=fileconflicts). I think P+O: issue-package (literally,
>>> package with that name) is the way to go (keeping in mind previous
>> And? Try --exclude=/bin/sh and see what breaks. Non-closure, or
>> mutually exclusive, ain't exactly rocket science. Indeed, its an if
> --exclude=/bin/sh to which program? rpm? I don't see such option...
Gak, I can never remember all the rpm options I never use:
$ rpm --help | grep exclu
--excludedocs do not install documentation
--excludepath=<path> skip files with leading component
I was referring to --excludepath, which should cause all
to fail to be satisfied, a case of CLI induced non-closure for
73 de Jeff
More information about the pld-devel-en