On Wednesday 09 June 2010 22:22:55 Daniel Leidert wrote:
a) The usual way is, that such a desktop-dependent package will depend
and pull in the required environment (compare it to e.g. a frontend of a
program for GTK vs QT - we have several examples in the repository). So
the user will see,
Am Dienstag, den 08.06.2010, 20:17 +0200 schrieb Stefan Haller:
On Monday 07 June 2010 17:28:19 Daniel Leidert wrote:
I would expect a simple third solution:
desktopnova depends on the modules with equal version
the modules don't depend on desktopnova at all
Why do they depend on
On 2010-06-09, Daniel Leidert daniel.leidert.s...@gmx.net wrote:
b) Let both modules packages provide desktopnova-module and conflict
with each other. Then let desktopnova depend on desktopnova-module. So
the user will have to choose the module package to install. IMO this is
a common
On Monday 07 June 2010 17:28:19 Daniel Leidert wrote:
I would expect a simple third solution:
desktopnova depends on the modules with equal version
the modules don't depend on desktopnova at all
Why do they depend on desktopnova atm? They don't contain anything that can
be run by a user
Hello mentors,
I’m the maintainer of the desktopnova package[1]. At the moment I’m trying to
fix bug #583756[2]. The binary packages have circular dependencies.
Currently there are four binary packages:
* desktopnova
* desktopnova-module-gnome
* desktopnova-module-xfce
* desktopnova-tray
Stefan Haller wrote:
I’m the maintainer of the desktopnova package[1]. At the moment I’m
trying to
fix bug #583756[2]. The binary packages have circular dependencies.
Currently there are four binary packages:
* desktopnova
* desktopnova-module-gnome
* desktopnova-module-xfce
*
Hello,
On 07/06/10 17:08, Stefan Haller wrote:
As far as I can see, there are currently two ways to avoid circular
dependencies:
[...]
(2) Rename the binary packages to:
* desktopnova-gnome
* desktopnova-xfce
* desktopnova-common
[...]
Solution #2 is much better,
7 matches
Mail list logo
