packaging rules

Aredridel aredridel at nbtsc.org
Wed Aug 1 23:23:57 CEST 2007


On Wed, 2007-08-01 at 22:06 +0200, Cezary Krzyżanowski wrote:
> 
> 2007/8/1, Patryk Zawadzki <patrys at pld-linux.org>:
>         Is there anything against switching all NameObsoletes
>         (Obsoletes: gdm
>         in kdm etc.) to conflicts or dropping them altogether?
>         
>         I am the admin and I want to decide what to install with what.
>         If I
>         want 2 login managers, that's my problem, if I want 3 smtp
>         services, 
>         that's my problem.
> 
> I'd suggest a help notice (I'm not sure is it possible with rpm -- I'd
> say poldek had to do it, as one of the nice features that drag ppl to
> us (mmazur(tm))). Something like: 
> "You are trying to install package %{name} which provides %{provides},
> but you've already have a package providing %{provides} installed in
> your system: %{packages_having_the_provided_thing_list}.
> 
> If you'd like to install it anyway use the --force option. 
> 
> Remember you have to manually configure the %{name} package to have it
> working side by side with %{packages_having_the_provided_thing_list}."
> 
> That + implementing + 4 policies in poldek (automatically force,
> automatically ignore without error, automatically fail with error (the
> present poldeks behaviour), ask the user). I *think* some further
> checking is needed, as there will happen situation, when the conflict
> macro means that the packages literally can't be installed in the same
> system side-by-side. 

Using just Provides: makes so much sense to me -- I've wished I could
have both installed at once several times without upgrades semi-silently
removing one. (An arch developer asked me yesterday how PLD handled
this.)

Aria
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : /mailman/pipermail/pld-devel-en/attachments/20070801/f20b342f/attachment.sig 


More information about the pld-devel-en mailing list