packaging rules

[Jeff Johnson]

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