Bug 149676

Reported upstream:
http://www.avahi.org/ticket/30

*** Bug 165771 has been marked as a duplicate of this bug. ***

*** Bug 166156 has been marked as a duplicate of this bug. ***

Raising severity because this package is getting installed by default.

Stanislav, why is it getting installed by default?

In my case avahi-compat-mDNSResponder was installed manually by replacing of mDNSResponder.

AFAIK, mDNSResponder should be installed by default, but I need a confirmation from anybody with fresh installation without manual changes.

Stefan, any idea how avahi-compat-mDNSResponder is getting installed by default on SL 10.1?

I don't. Only mDNSResponder is installed by default.

Alberto, did you select any extra packages?  I don't even see the package on the media for RC1.

Stanislav could the /usr/lib/libdns_sd.so be being filled by the wrong package?

I did a netinstall, only choosing the standard GNOME selection.

I then installed the kernel development selection, but the problem was already present before this addition.

libdns_sd.so is provided by two packages - mDNSResponder and avahi-compat-mDNSResponder.

AFAIK, mDNSResponder should be a part of one of basic selections.

Package manager must:

- either ask you to decide between mDNSResponder and avahi-compat-mDNSResponder, if mDNSResponder is not part of any selection

- or install mDNSResponder, if mDNSResponder is part of any selection

- or replace mDNSResponder by avahi-compat-mDNSResponder, if user explicitly selects avahi-compat-mDNSResponder

Stefan, do we have mDNSResponder as part of the basic selections?

No, it's only in our default selections for KDE/Gnome.

I've submitted packages that fix the compat layer to do the right thing in two spots that were causing problems so the nautilus and gnomemeeting crashes are solved now.

I think I agree with stanislav that zypp should prefer a package in the selection (or pattern) if it has two possible resolutions to the problem.  Moving to libzypp  for consideration.
 
I don't think this is critical any longer, I'll make it normal, but please review AJ.

Current state on RPM level is:

mDNSResponder-lib:
Obsoletes:      avahi-compat-mDNSResponder

mDNSResponder-lib-devel:
Obsoletes:      avahi-compat-mDNSResponder-devel

avahi-compat-mDNSResponder:
Provides:       mDNSResponder-lib mDNSResponder
Obsoletes:      mDNSResponder-lib mDNSResponder

avahi-compat-mDNSResponder-devel:
Provides:       mDNSResponder-devel
Obsoletes:      mDNSResponder-devel

I think, it is technically correct - avahi-compat-mDNSResponder* provides comatibility interface, user can decide one or another and RPM removes the second.

Because only mDNSResponder is in selection and no package requires avahi-compat-mDNSResponder (with exception of avahi-compat-mDNSResponder-devel), I can expect, that without any user interaction, avahi-compat-mDNSResponder should never be installed.

comment #13. The solver already does this, it prefers those packages of multiple possibilities that are already installed or marked for installation.

comment #14: I don't think these dependencies are correct. Imho, the two packages should conflict one another.
Adding mls to comment.

I agree with Klaus, Conflicts is much saner here than obsoletes. And I remember that you said in the mail thread "alternative implementation - how
to set Requires/Provides/Obsoletes" that you use conflicts, so I'm a surprised that it suddenly is provides/obsoletes.

And, as I stated in the mail, I don't like that avahi provides mDNSResponder.

Using Conflicts disables seamless replacement of one by another and requires to use --nodeps tricks to do it. That is why I added Obsoletes to both implementations.

But it is possible to remove Provides. It will bring problems to people, who want to compile packages in their live system with avahi-compat-mDNSResponder-devel, but maybe can fix this problem.

I can also remove the Provides only from avahi-compat-mDNSResponder.

Who needs "seamless replacement"? We also don't do this for sendmail/postfix and the like.

sendmail and postfix have different API, ABI and configuration.

mDNSResponder and avahi-compat-mDNSResponder has exactly the same API and ABI, but uses different back-ends to provide service.

At least users of native avahi applications (e. g. rhythmbox) wants seamless replacement of mDNSResponder, because it's the only solution to make both native avahi applications and native mDNSResponder applications (and native howl applications) work correctly together.

The point is that with your "Obsoletes" you're telling the solver that avahi-compat-mDNSResponder is "newer" than mDNSResponder, so the solver will prefer avahi. This is not what we intend.

But mDNSResponder contains Obsoletes: avahi-compat-mDNSResponder, too.

Correction: mDNSResponder-lib contains Obsoletes: avahi-compat-mDNSResponder and avahi-compat-mDNSResponder contains Obsoletes: mDNSResponder-lib.

Well, IMHO that's also wrong ;-)

Maybe this will fix the problem:

selectio:
Fri Apr 21 12:57:51 CEST 2006 - sndirsch@suse.de

- GNOME2/KDE-DESKTOP-DEPS/MONO: added mDNSResponder-lib

Comment #25: No, it will not. This is completely unrelated.

Fix the dependencies of your packages. If two packages provide conflicting functionality (and files), "Conflicts:" is the _only_ dependency to express this correctly.

ok, we have more than avahi in that corner ...

all these packages obsolete existing other packages:

gnome-panel* vs gnome-panel-nld
aspell-nb vs aspell-no
libzypp* vs yast2-packagemanager
bluez-utils vs bluez-hciemu
release-notes-slessp1 vs release-notes
avahi vs mDNSResponder-lib
mDNSResponder-lib vs avahi
release-notes-sles vs release-notes
gnome2-NLD vs gnome2-SuSE
release-notes-sled vs release-notes

comment #28: Which of these are shipped with the product ?

Provides/Obsoletes to express "package X upgrades Y" are correct.

(libzypp obsoleting yast2-packagemanager is correct since libzypp is an upgrade replacement for yast2-packagemanager)

gimp vs. gimp-unstable has the same problem.

gnome-panel* vs gnome-panel-nld can be OK. Ole is for NLD (and it should replace gnome-panel-there), one for box (and it will maybe replace gnome-panel-nld in future).
The same should be valid for gnome2-NLD vs gnome2-SuSE.

aspell-no souds like a mistake - we spent many time to get rid no_NO.

Not sure about other packages.

---

To avahi vs. mDNSResponder:

Let's say, that both provide libdns_sd.so.1 (they do).

Then I will replace Obsoletes by Conflicts for both and the main problem will be fixed.

The second part of the fix is more compicated - replace mDNSResponder-devel in BuildRequires by a virtual symbol or /usr/include/dns_sd.h. But it is a low priority, maybe for 10.2.

What should I do for gimp vs. gimp-unstable?

Fixed for avahi and mDNSResponder-lib by removing Provides and replacing Obsoletes by Conflicts. Decreasing preiority, but not closing, because there are other packages with the same problem.

Technically it is not yet absolutely correct, because avahi daemon cannot work properly if mDNSResponder daemon is running. But because avahi daemons are in the same package as the library, I did not add these Conflicts keywords - it would introduce ugly conflicts while installing rhythmbox.

I use yum and its resolver doesn't make a choice between the two package families, so each time I execute "yum upgrade" system ask me to install (to substitute) the installed family with the other one.

See bug #169781 for more details.

Carlo

Fixed by upstream long time ago.