Dear Debian developers,
Following a post to Debian-Devel-Announce, I would like to
discuss getting rid of circular dependencies.
Why ?
-----
1) The semantic of Depends specified by Debian policy 7.2. does not allow
packages with circular dependencies to be installed at all:
`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.
This mean that dpkg have to go out of its way to install them, and doing
that break the expectation of packages expecting Depended package to be
configured before them.
2) There have been lots of evidence that circular dependencies create
problems during upgrade. See bugs #310490 in particular
<[EMAIL PROTECTED]>.
3) Circular dependencies make the job of the testing scripts harder.
4) Circular dependencies make bootstrapping a new plateform harder.
5) There is an urban legend that circular dependencies between packages
build from the same source are harmless. This is false of course. Being
part of the same source package has no effect of the Packages.gz file
whatsoever.
Which ?
-------
Preferably all of them.
Robert Lemmen was kind enough to set up a summary of current circular
dependencies: <http://debian.semistable.com/debgraph.out>
See the list for yourself.
The circular dependencies involving the largest number of packages are:
* libxtst6 libxtrap6 libxrandr2 libxp6 libxt6 libxmu6 libxi6 libxrender1
libxft1 libsm6 xlibs
* libgnorba27 libgnomeui32 libgnomesupport0 gnome-bin gnome-libs-data libgnome32
* xemacs21-gnome-nomule xemacs21-gnome-mule-canna-wnn xemacs21-gnome-mule
xemacs21-nomule xemacs21-mule-canna-wnn xemacs21-bin xemacs21-support
xemacs21-mule xemacs21
* gnome-panel-data gnome-panel nautilus gnome-control-center capplets
gnome-session
* phpgroupware-preferences phpgroupware-admin phpgroupware-setup
phpgroupware-phpgwapi phpgroupware
* wesnoth-tdh wesnoth-ei wesnoth-sotbe wesnoth-trow wesnoth-httt
wesnoth-data wesnoth
How ?
-----
I see two easy case:
1) foo and foo-data. There is usualy no reason for foo-data to depend on
foo. foo-data does not provide user-visible interface, only data, so it
does not need to depend on foo.
2) libfoo and foo-bin, where foo-bin include binaries linked with
libfoo. Usually libfoo only need to Depends on configuration data
in foo-bin and not on any binaries linked with libfoo (to avoid infinite
recursion). In that case it should be possible to split foo-bin in
foo-bin and foo-common, and change libfoo to depend on foo-common
instead.
Other options ?
Cheers,
--
Bill. <[EMAIL PROTECTED]>
Imagine a large red swirl here.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
