avahi should be downgraded to Recommends:

[Loye Young]

Binary package hint: ubuntu-desktop

All avahi programs and libraries (and its multicast cousin libnss-mdns) should be downgraded to a Suggests dependency (or at most Recommends). This is of great importance because business organizations are not installing (*)ubuntu because of the presence of avahi and the difficulty involved in removing it from the installation.

The Debian Policy Manual describes the appropriate uses of the various dependencies:
[quote]
Depends
    This declares an absolute dependency. A package will not be configured unless all of the packages listed in its Depends field have been correctly configured.
    The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality.
Recommends
    This declares a strong, but not absolute, dependency.
    The Recommends field should list packages that would be found together with this one in all but unusual installations.
Suggests
    This is used to declare that one package may be more useful with one or more others. Using this field tells the packaging system and the user that the listed packages are related to this one and can perhaps enhance its usefulness, but that installing this one without them is perfectly reasonable
[/quote]

Avahi does not provide any functionality under most circumstances (because the rest of the local network has to be configured for it), and even in circumstances when it does provide some functionality, it's not an essential function. Certainly, reasonable minds can differ on whether it should be installed at all. Many of us in the community (myself included) believe that [avahi / zeroconf / rendezvous / bonjour] is fundamentally a bad idea and should not be implemented at all, but other reasonable minds like avahi. This is exactly the situation for which Suggests is best suited for.

Some in the community are of the opinion that the best solution is to install it, but not enable it by default. From the outset, such an argument essentially agrees that avahi is not an essential or even a strong dependency, which would dictate a Suggests dependency level. Further, avahi-daemon, avahi-autoipd, libavahi-*, and libnss-mdns run processes and scripts that interfere with other programs and make setting up a secure, centrally managed network in a business setting extremely troublesome. It has cost me personally several occasions of spending all night reconfiguring the network of an entire organization, usually when upgrades overwrite configurations.

It's not simply a bug in avahi; it is the fundamental nature of avahi to interfere with the networking protocols. This creates havoc with networks configured for stability and security rather than for ease of use.

Uninstalling the desktop metapackage is not a reasonable work-around because the metapackage ensures clean and automatic upgrades.

While I sympathize with those who want to make the home computer of Mom and Pop "just work" without configuring anything, surely the advocates of avahi can sympathize with those of us who are trying to bring Ubuntu to businesses and organizations.

Happy Trails,

Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://www.iycc.biz

[Cody A.W. Somerville (cody-somerville)]

Thank you for your suggestion. However, the changes you are requesting aren't really a bug and require more discussion, which should be done on an appropriate mailing list or forum. http://www.ubuntu.com/support/community/mailinglists might be a good start for determining which mailing list to use.

[Loye Young (loyeyoung)]

> the changes you are requesting aren't really a bug

Your work in the Ubuntu community is noteworthy and commendable, but your comment evinces that you haven't been affected by the problem. Perhaps, then, you are not in the best position to make such an assessment. As the old saying goes, "One man's bug is another man's feature."

It would be difficult to find a dependency that is more "bug-like" than this one. Incorrect dependencies are indeed a bug if they interfere with other packages or if they cause problems with updates. In this case, dragging in something as pernicious and insidious as avahi causes severe problems with network connectivity because avahi-daemon, avahi-autoipd, and libnss-mdns override configurations set up by the network administrator. The "disabling" of avahi-daemon in /etc/default/avahi-daemon is often cited as a potential solution, but that only disables part of avahi's interference with the network configuration. The pervasive changes to the networking stack, which are required to make the avahi family of packages work, end up being next to impossible to disable short of uninstalling the packages themselves.

Simply removing the offensive packages does solve the networking problem, but the dependency issue prevents clean upgrades in the future. Because ubuntu-desktop depends on avahi-daemon, avahi-autoipd, and libnss-mdns, removing them requires removing ubuntu-destop as well. Removing ubuntu-desktop, in turn, causes upgrades not to perform as expected. (See the package description of ubuntu-desktop.) Thus, the impetus for this bug report.

>require more discussion

There's nothing to be gained by discussion in the mailing lists. Avahi's functionality has already been argued about for two or three years now. Discussions on the mailing lists inevitably devolve to a stalemate between two competing use cases: If you have a small, ad-hoc network and understand avahi's untrustable nature, avahi can be a convenience. But if your network is large enough to require central administration, trust relationships among network clients, and/or stable IP addressing via DHCP server administration, avahi causes innumerable headaches. (If you haven't had the opportunity to implement avahi-laden Ubuntu desktops in an organizational environment, you have been spared much frustration.)

The server team had an extended conversation about avahi last November. Although the efficacy and advisability of avahi was hotly disputed, everyone seemed to agree that avahi should not be on a server, or for that matter, any system that is not behind a firewall. Eventually, we dropped the discussion and agreed that avahi is one of several reasons that the Ubuntu Server Edition should not ship with any of the currently configured desktop environments.

Although I am persuaded that reasonable minds can differ regarding the efficacy and utility of avahi. Avahi, for those who understand its limitations and in the right use case, does what it's designed to do. Seen in that light, avahi can be considered an alternative protocol for ad hoc networking, in contrast to the standard and ubiquitous DHCP. Because the basic networking stack already includes DHC...

[Cody A.W. Somerville (cody-somerville)]

It seems that you feel strongly about this issue. However, in my opinion, simply leaving this bug open will do little but infuriate you with the inaction taken on it. I recommend that you pursue this concern with the Ubuntu Technical Board. The Ubuntu Technical Board is responsible for the technical direction that Ubuntu takes. The Technical Board makes final decisions over package selection, packaging policy, installation system and process, toolchain, kernel, X server, library versions and dependencies, and any other matter which requires technical supervision in Ubuntu. You can find more information about the Ubuntu Technical Board and the procedures employed by it at http://www.ubuntu.com/community/processes/techboard

[Loye Young (loyeyoung)]

> It seems that you feel strongly about this issue.

Yeah. It seems that way. :-)

> leaving this bug open will do little but infuriate you with the inaction taken on it.

I appreciate your concern for my feelings, but you needn't worry. As you intuit, open decision-making in communities is sometimes slow and frustrating, but patience, openness, and candor make for a better result on the whole. The process allows us, indeed expects us, to advance our thoughts passionately. But this isn't my first rodeo, so I don't expect that my emotive state will suffer. Perhaps the slings and arrows of past misfortunes afford me a bit of perspective.

> I recommend that you pursue this concern with the Ubuntu Technical Board.

I have great respect for the Big Kahuna and his lieutenants on the UTB, and their decision would of course be dispositive. (As Mel Brooks once said, in a certain cinematic classic, "It's good to be the king.") However, this bug affects many people, who may have substantive comments, and allowing sufficient time for all to consider the issue and participate is a necessary part of the process.

[Oliver Grawert (ogra)]

not a dependency of edubuntu-meta

[Oliver Grawert (ogra)]

not a dependency in edubuntu-meta

[oss_test_launchpad (oss-test-launchpad)]

> This is of great importance because business organizations are not installing (*)ubuntu because of the presence of avahi and the difficulty involved in removing it from the installation.

Can you name any of such companies?

[Loye Young (loyeyoung)]

> Can you name any of such companies?

No, because they are my customers and they don't cotton to me telling
the world about their internal decision-making.

[Cody A.W. Somerville (cody-somerville)]

So, if I read your request correctly, moving avahi-daemon from depends to recommends would be satisfactory?

[Loye Young (loyeyoung)]

> So, if I read your request correctly, moving avahi-daemon from depends
> to recommends would be satisfactory?

You'd need to move all three of avahi-daemon, avahi-autoipd, and
libnss-mdns, because they work in concert. A convenient method may be
to create a recommends dependency on a separate "avahi-desktop"
package that depends on all three.

It's not an optimal solution, but it is a workable one. As I have
written at length on many occasions, avahi is insecure and unreliable
for users, imposes an unnecessary burden on the Internet at large,
and should be deprecated (certainly not installed by default). A
"suggests" dependency would require a conscious decision to activate
and is much preferred. However, moving "los tres diablos" to
recommends would at least allow a user to purge them and still
preserve smooth upgrades.

[Martin Pitt (pitti)]

Can you name some reasons why you believe that nss-mnds and avahi are compromising security? I don't see any, they just help you to make it easier to find and use network services, they do not enable any service themselves. The security implications come with the question whether you actually trust and *use* a service (like DAAP in Rhythmbox, or sshing to foo.local instead of an IP number). nss-mdns and avahi do not, and cannot, change anything in your personal trust relations.

Calling avahi "pernicious and insidious" is unfounded, and to be honest, it's just plain FUD. It might indicate that you misunderstood the purpose of it? Avahi just provides a service catalog, nothing more. Nothing in the desktop depends on it, or even assumes that it provides correct information, and desktop services like DAAP music sharing are not even enbaled by default. We only enable libnss-mnds by default, because it doesn't change any security properties of name resolution.

So I strongly object against dropping avahi and libnss-mdns from the seeds (mind that the entire purpose of *-desktop is to pull in packages, which makes Suggests: totally worthless). Avahi and nss-mdns ease the usage of network services, which is an important thing in a "make it just work" desktop distribution.

However, I do agree that they should be changed from Depends: to Recommends: (like libnss-mdns already), so that you can uninstall them without removing *-desktop. I don't think there is a particular reason for making them strong dependencies, that's more or less just because of historical reasons.

[Martin Pitt (pitti)]

I'll take care for ubuntu-meta.

[Martin Pitt (pitti)]

Looking at this further, avahi-autoipd and libnss-mdns are already recommends, and seeded in various *buntu-desktop, so that does nto need to change. avahi-daemon is seeded in platform.intrepid, I changed that to a recommends now in the seeds [1]. So as soon as any of the -meta packages get rebuilt, this will be fully fixed.

[1] http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.intrepid/revision/1202

[Loye Young (loyeyoung)]

As we say here in Texas,

Yee Hah!

<applause />

--
Loye Young
Isaac & Young Computer Company
Laredo, Texas

[Jonathan Thomas (echidnaman)]

Should be fixed in kubuntu-meta now.

[Jonathan Thomas (echidnaman)]

Also ubuntu-meta.