Comment 31 for bug 657564

Hello and sorry for this late answer...

> What do you mean that Debian is refusing to apply patches from upstream? What are these patches? Are there bugs about them in Debian's bug tracker, and why doesn't upstream just release a new tarball? Unless you really mean that upstream prefers a certain packaging layout which is not something that upstream needs to worry about.

We (the developers of Cairo-Dock) don't like our Debian packages for a few reasons:
 * About Cairo-Dock (core):
  - Their patches are strange...They change the version number! Maybe there is a good reason but they do that without posting any message here or on our forum. This is a bit annoying because that's change the name of our soname, of our themes, of all .conf files and it's also a problem when we have to debug something or if we add some restriction about the version (about our plug-ins).
  - They change our default theme. I can understand that they replace firefox by iceweasel but now, if firefox is not available it will use iceweasel. But I don't understand why they change the terminal application... They can propose to us to change something, it's not a problem but they force this modification....
  - cairo-dock-core and cairo-dock-data have been merged, but why? Is it not a recommendation to split this kind of packages like that?
* About Cairo-Dock Plug-Ins:
  - They have changed the name of the package (cairo-dock-plug-ins -> cairo-dock-plugins). Ok, it's the official name (set in the CMakeLists.txt file but not on Launchpad and BZR) but this package has been uploaded on Ubuntu before to be uploaded on Debian and this package has been proposed on Debian with the same name.
  - The version has been changed too but it's a problem if there is a modification in the API because the dock checks if we use the same version (core and plug-ins)
  - They have split each plugin in one package per plugin but it's not a good idea for a few things (see above) (e.g. it's harder to maintain it: the name can change, one plugin can be required by another, our themes can be modified, our new plug-ins are often missing, etc.)
  - A few files are missing (e.g. for our DBus plugin)
  - Our 'integration' plug-ins do not required of any dependences (we do not have to use shlibs for them) because they are used only if a library is available (e.g. our XFCE plug-in is activated only if thunar and gvfs is available but you don't need to install thunar and all other XFCE lib if you're using LXDE... a lot of useless dependences (more than 30Mo I think) are installed and it's a bit ridiculous (bug already reported two years ago I think)
  - Our unstable plug-ins are compiled and installed, why? And our new plug-ins are not available...
  (...)
I've proposed a new version of these two packages on mentors.debian.net (see above) but these modifications have been rejected (not all of them, thank you for these modifications but it's not enough...). I've also proposed to maintain these packages but without any success (yes, I'm an Ubuntu user so I guess I'm not able to do that... even if I'm a former Debian user.? :) but it will be so easier...)

Also I want to note that these plug-ins packages have been included first in Ubuntu (I don't know why but our previous maintainer wanted to do that...) and then in Debian but the Debian maintainers have change the name and all the content of the debian directory :-/

> Please stop pushing to this duplicate source package and have the Debian named package provide the same named transitional packages so that upgraders will get the correctly named packages.

Do I have to rename the source package? ('cairo-dock-plugins' instead of 'cairo-dock-plug-ins')

> Anyway, the reason I came here was because your package needs to not depend on indicator-me since that has been removed from the Ubuntu repositories.

It will be fixed with the next version, thank you!

PS: the most important thing that we don't like it's that it seems they don't listen to the devs of the applications... If these maintainers want to change something, it's not a problem but it's much better to discuss with the devs, no? And if these devs want to change something, I think the maintainers have to listen to them or talk to them. Or maybe I'm wrong and it's too hard/takes too many time to do that.