packaging rules

[Jeff Johnson]

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 ;-)

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

hth

73 de Jeff

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2205 bytes
Desc: not available
Url : /mailman/pipermail/pld-devel-en/attachments/20070807/df2c69e5/attachment.bin