Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#22765 - [avahi] split package into libs and frontends

Attached to Project: Arch Linux
Opened by Greg (dolby) - Saturday, 05 February 2011, 04:30 GMT
Last edited by Gaetan Bisson (vesath) - Saturday, 12 February 2011, 12:20 GMT
Task Type Feature Request
Category Packages: Extra
Status Closed
Assigned To Gaetan Bisson (vesath)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

I think that avahi is one of the packages that makes sense to split.
It contains libraries, frontends, daemons, intergration with QT3, QT4 , GNOME, mono bindings, the whole lot.
A long list of (heavy) optional dependencies:
gtk2: avahi-discover-standalone
qt3: qt3 bindings
qt: qt bindings
pygtk: avahi-bookmarks, avahi-discover
twisted: avahi-bookmarks
mono: mono bindings
dbus-python: avahi-discover
nss-mdns: NSS support for mDNS

And yet its packaged as a single tarball.
I dont know the exact details cause i dont know avahi that well, but it seems to be that it could split, possibly into more than 2 packages.
This task depends upon

Closed by  Gaetan Bisson (vesath)
Saturday, 12 February 2011, 12:20 GMT
Reason for closing:  Won't implement
Comment by Gaetan Bisson (vesath) - Saturday, 05 February 2011, 08:59 GMT
Who cares if the dependencies are heavy when they are optional?
Having just one package is much simpler and consistent with upstream.
Since the compressed size is 500KB there is no size issue either.
Why should it be splitted?

Loading...