[Fedora-packaging] Conflicts

Tom 'spot' Callaway tcallawa at redhat.com
Fri Mar 4 16:45:56 UTC 2005


On Fri, 2005-03-04 at 17:12 +0100, Michael Schwendt wrote:
>What is the official policy about packages in Fedora Extras which
>marked as conflicting with eachother?
>
>E.g. Sylpheed (dropped from Rawhide) and Sylpheed-claws share file names
>for main binary, manual page, pixmap file, desktop file. And since
>Sylpheed-claws is the feature-enhanced bleeding edge development fork of
>Sylpheed, there may be other conflicts. While this particular conflict
>could be resolved by renaming the files, this would be contrary to what
>upstream does.

Packages in Extras should not conflict with packages in Core, when we're
effectively talking about the same package. If foo-bar is just a newer
version of foo, then it needs to be updated in Core (or moved to extras,
where it can be foo-bar).

>As another example, gpgme03-devel and gpgme-devel. Used to building
>in clean build environments where only the needed build requirements
>are pulled in, there was no need to relocate either package and make
>it possible to install both at once.

Hmm. I think in the case of foo3 and foo, if they need to be installed
at the same time, they need to follow the openssl example, and not
conflict.

>I think there are other extras which conflict because they provide same
>or similar functionality, not limited to "leafnode" and "suck",
>"oidentd" and "pidentd" (core), "proftd" and "vsftpd anonftp" (core).

In some cases, we might be able to use the alternatives system, so that
"identd" and "ftpd" are what we actually use, and have the rpms
"Provide" the alternatives name. Then, the user can use alternatives to
switch between the options.

As usual, I'm open to suggestions on this.

~spot
---
Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!




More information about the Fedora-packaging mailing list