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
> rest;
> 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:
Obsoletes: /usr/lib/lpd
will erase all other printer daemons when installing a new printer
daemon.
>
> - some people want to be able to install more than one package
> providing
> similar functionality, like HTTP or SMTP servers)
>
This is the "alternatives" problem. Why one would want 1-of-N behavior
has
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.
>
Yup.
>
> 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
> for
> Obsoletes tag, e.g.:
>
> "Obsoletes(replacement):" (or "Replaces:"?) for mutually exclusive
> packages
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
one.
These days so many packages have been renamed, that virtual Provides:
are quite common, so I'd use
Provides(hint): oldname
instead of
Obsoletes(replaces): oldname
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
>>> exclusive
>>> 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,
>>> virtual
>>> package with that name) is the way to go (keeping in mind previous
>>> paragraph).
>>>
>>
>> And? Try --exclude=/bin/sh and see what breaks. Non-closure, or
>> enforcing
>> mutually exclusive, ain't exactly rocket science. Indeed, its an if
>> statement
>> somewhere.
>
> --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
<path>
I was referring to --excludepath, which should cause all
Requires: /bin/sh
to fail to be satisfied, a case of CLI induced non-closure for
dependencies.
73 de Jeff
_______________________________________________
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
