packaging rules

Jakub Bogusz qboosh at pld-linux.org
Tue Aug 7 23:00:04 CEST 2007


On Tue, Aug 07, 2007 at 03:36:41PM -0400, Jeff Johnson wrote:
> On Aug 7, 2007, at 3:24 PM, Jakub Bogusz wrote:
>> On Fri, Aug 03, 2007 at 06:48:09PM +0200, Patryk Zawadzki wrote:
>>> So, is there anything against using feature-provides and conflicts
>>> (only for really conflicting packages)?
>>>
>>> Old packages should not be a problem if we rebuild all affected software.
>>
>> It is a problem as just rebuilding them don't force installing them on all
>> existing machines. In such cases I propose changing package name Obsoletes
>> to Conflicts: package-name < (E:V-R before Provides has been added).
>>
>
> If you want Conflicts: behavior instead of Obsoletes: (or vice versa), its 
> rather
> trivial, like max 200 lines of code, to attach underlying semantic 
> attributes, like persistence (ala Conflicts)
> with discovery/autoerasenewer (like Obsoletes:).
>
> All I ask is a a clear consensus on what is desired in rpm ;-)

Currently we can't make a consensus ourselves ;)
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)
- 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:
- some people want to be able to install more than one package providing
  similar functionality, like HTTP or SMTP servers)

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 for
Obsoletes tag, e.g.:

"Obsoletes(replacement):" (or "Replaces:"?) for mutually exclusive
  packages
"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)

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...


-- 
Jakub Bogusz    http://qboosh.pl/


More information about the pld-devel-en mailing list