Duplicated package with cairo-dock-plugins (coming from Debian)

[Fabrice Coutadeur]

Binary package hint: cairo-dock-plug-ins

Hi,

After syncing cairo-dock-plugin package from debian, we now have two time the same source in the archive. Please work with Debian to be able to merge the 2 packages, and have it only once.

Thanks,
Fabrice

[Matthieu Baerts (matttbe)]

Hello Fabrice,

Thank you for this bug report!
I was already notified by this problem and I wanted to open a bug report too. So now, it's time to fix it :)

[Matthieu Baerts (matttbe)]

Hello Nobuhiro Iwamatsu,

The current version of Cairo-Dock is the 2.2.0 where Autoconf has been replaced by CMake.
I've updated the 'debian' configuration's files and you can see: this version is also available in the current repository of Ubuntu (Maverick 10.10).
So I just want to know if it's possible the sync these packages with those for Debian? So the cairo-dock-plugins packages will be deprecated and replaced by cairo-dock-plug-ins.
If you want, I can maintain these packages in Debian too :) . I think it's maybe the best solution because I already maintain Ubuntu packages. Also I'm part of the Cairo-Dock team so I am aware of almost everything ;)
What do you think about that? :)

PS: of course, I don't have the right to upload into debian repositories and I need a sponsor for that (and also to check a second time if everything is ok ;) ). So if you want, you're welcome ;) (but I can also contact someone else :) )

[Matthieu Baerts (matttbe)]

@Matthias Klose:

Hello doko,
Is it possible to remove this source (cairo-dock-plugins) from the repositories? :)

Thank you for your help!

[Nobuhiro Iwamatsu (iwamatsu)]

Hi,

2010/10/10 Matthieu Baerts <email address hidden>:
> Hello Nobuhiro Iwamatsu,
>
> The current version of Cairo-Dock is the 2.2.0 where Autoconf has been replaced by CMake.
Yes, I know this.
I already did packaging this on my local repository.
But I dont upload this to Debian. Because Debian is being freeze.

> I've updated the 'debian' configuration's files and you can see: this version is also available in the current repository of Ubuntu (Maverick 10.10).
> So I just want to know if it's possible the sync these packages with those for Debian? So the cairo-dock-plugins packages will be deprecated and replaced by cairo-dock-plug-ins.
> If you want, I can maintain these packages in Debian too :) . I think it's maybe the best solution because I already maintain Ubuntu packages. Also I'm part of the Cairo-Dock team so I am aware of almost everything ;)
> What do you think about that? :)

Please enter our team with pleasure if you package *Debian* Package
and maintain it :-).
However, you need to maintain and confirm working in both distribution.
And it is necessary to always maintain packages of Debian as upstream.

>
> PS: of course, I don't have the right to upload into debian repositories
> and I need a sponsor for that (and also to check a second time if
> everything is ok ;) ). So if you want, you're welcome ;) (but I can also
> contact someone else :) )

OK, No problem :-)

Best regards,
  Nobuhiro

--
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6

[Nobuhiro Iwamatsu (iwamatsu)]

Hi,

2010/10/10 Matthieu Baerts <email address hidden>:
> @Matthias Klose:
>
> Hello doko,
> Is it possible to remove this source (cairo-dock-plugins) from the repositories? :)
>

We(Debian) cannot delete it now.
This work will start it after squeeze was released.

Best regards,
  Nobuhiro

--
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6

[Matthieu Baerts (matttbe)]

Hello Nobuhiro,

> > Is it possible to remove this source (cairo-dock-plugins) from the repositories? :)
> >
>
> We(Debian) cannot delete it now.
> This work will start it after squeeze was released.
Not in Debian now but in Ubuntu ;) => http://archive.ubuntu.com/ubuntu/pool/universe/c/cairo-dock-plugins/
I think it's a question for doko :)

> Please enter our team with pleasure if you package *Debian* Package
> and maintain it :-).
I think it can be really interesting! I already maintain Ubuntu deb packages and I think it's not a problem for me to do the same for Debian distribution. I can use a LiveUSB to test it with pbuilder, etc. ;)
But of course, I'll do that after this Debian freeze (not until December I guess) but I have a few questions about that:
* What do I have to do to join your team?
* What's the easiest way for you when I want to propose a new version in order to have your sponsor?
  - To push this version to another branch (+where?)? or to have the right to upload to the same branch?
  - Or use a bzr branch in LP?
  - Or to upload the new debdiff? (+where?)
  - Is it possible to use "bzr bd"?
  - Can I open a bug in LP instead of Debian bug tracker?

Thank you for your help :)

Regards,

Matttbe

[Matthias Klose (doko)]

the outcome should be a package with the same source name, and with the same binary package names,so that we don't have unresolved dependencies/recommendations, etc. such a package could be prepared in experimental (not frozen), on a bzr branch, or in a PPA.

[Matthieu Baerts (matttbe)]

Hello,

@Nobuhiro Iwamatsu: I've uploaded new packages on mentors.debian.net
I've tested these packages by building them with pbuilder (sid distribution) and by installing them on a fresh install of Debian Sid (today updated).
Is it possible to have your sponsoring? Of course I can ask that to someone else but the bad thing is that this package has to be push on debian repositories before this Thursday 24: it's the day of the Feature Freeze in Ubuntu Natty 11.04.

Regards,

Thank you

http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=cairo-dock
http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=cairo-dock-plugins

[Nobuhiro Iwamatsu (iwamatsu)]

Hi,

We are maintaining cario-dock package on alioth.
If you dont have accout of alioth, please create accout.
And teach me your accout.
I will add you cairo-dock maintain team.

Best regards,
  Nobuhiro

2011/2/21 Matthieu Baerts <email address hidden>:
> Hello,
>
> @Nobuhiro Iwamatsu: I've uploaded new packages on mentors.debian.net
> I've tested these packages by building them with pbuilder (sid distribution) and by installing them on a fresh install of Debian Sid (today updated)

[Matthieu Baerts (matttbe)]

Hello Nobuhiro,

My account name is "matttbe" (matttbe-guest)
=> https://alioth.debian.org/users/matttbe-guest/

Thank you for your help,

Best Regards,
Matt

[Nobuhiro Iwamatsu (iwamatsu)]

Hi,

2011/2/21 Matthieu Baerts <email address hidden>:
> Hello,
>
> @Nobuhiro Iwamatsu: I've uploaded new packages on mentors.debian.net
> I've tested these packages by building them with pbuilder (sid distribution) and by installing them on a fresh install of Debian Sid (today updated)

[Nobuhiro Iwamatsu (iwamatsu)]

Hi,

2011/2/21 Matthieu Baerts <email address hidden>:
> Hello Nobuhiro,
>
> My account name is "matttbe" (matttbe-guest)
> => https://alioth.debian.org/users/matttbe-guest/
>

I already appied your accout.
Welcome!

Nobuhiro
--
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6

[Matthieu Baerts (matttbe)]

2011/2/21 Nobuhiro Iwamatsu <email address hidden>

> Hi,
>
> Package: cairo-dock-plug-ins
> Section: graphics
> Architecture: any
> Conflicts: cairo-dock-plug-ins (<= 2.0.8.0)
> Replaces: cairo-dock-plugin-data,
> cairo-dock-plugins,
> cairo-dock-alsamixer-plugin,
> cairo-dock-animated-icons-plugin,
> cairo-dock-cairo-penguin-plugin,
> cairo-dock-clipper-plugin,
> cairo-dock-clock-plugin,
> cairo-dock-compiz-icon-plugin,
> cairo-dock-dbus-plugin,
> cairo-dock-desklet-rendering-plugin,
> cairo-dock-dialog-rendering-plugin,
> cairo-dock-drop-indicator-plugin,
> cairo-dock-dustbin-plugin,
> ....
>
> NAK.
> Most users do not need all plugin.
> We should leave the choice that user can install only necessary plugin.
> cairo-dock-plug-ins is a meta package of that purpose.
>
> Best regards,
> Nobuhiro
> --
> Nobuhiro Iwamatsu
> iwamatsu at {nigauri.org / debian.org}
> GPG ID: 40AD1FA6
>

Yes we (the upstream) know but there is a lot of reasons to not split these
plug-ins:
* It's hard to maintain these deb packages (some plugins are available on
Ubuntu and not on Debian, some plugins are unstable, some plugins require
some other, some plugins can become unstable or the name can change, or some
plugins can merged, etc.)
* It's hard for us to manage our personal repository (we can use debarchiver
on our server ... :-/)
* If the user want to install Cairo-Dock, he will install 'cairo-dock'
package... so with all plug-ins. Perfect! But how can he know which plug-ins
he can remove? Maybe this plugin is used in a theme? Or needed by another
plugin? Moreover a plugin is not loaded if it's not enabled... So it's hard
to have a good reason except if you want to have a few kilo-bytes :-/
* We know that it can be interesting for a few people to have the
possibility to not install all applets but only some of them. But we guess
that these guys can also easily rebuild the package or compile Cairo-Dock
from source code with some CMake flags.

So... please do not split plugins packages like before, it's a request from
the upstream...

I already appied your accout.
> Welcome!

Thank you :)

[Fabounet (fabounet03)]

oh yes please do not split the plug-ins, it's so hard to maintain for no good in the end:
- some plug-ins are like necessary (*) (for instance, if you remove the Animations plug-ins, your dock will not react to anything with the usual animation, which is a very strange behavior. If you don't want animations, you can deactivate them in the config.)
- some plug-ins provide components that are expected by other applets (*) (for instance the Dbus plug-in provides a Dbus interface, and many applets run on top of this interface)
- the user can enable/disable a plug-in in the config panel much more easily than from Synaptic (root password needed, heavy GUI)

(*) so why are they plug-ins and not part of the core ? not because we want to have the possibility to deactivate them (although it's possible, as you can see it's totally useless), but because the core should be very minimalistic, and should provide a framework only. We want the other components to be isolated from each other.
This is a strong architecture, and many programs use it (for instance Compiz).

[Nobuhiro Iwamatsu (iwamatsu)]

Hi,

2011/2/21 Matthieu Baerts <email address hidden>:
> 2011/2/21 Nobuhiro Iwamatsu <email address hidden>
>
>> Hi,
>>
>> Package: cairo-dock-plug-ins
>> Section: graphics
>> Architecture: any
>> Conflicts:  cairo-dock-plug-ins (<= 2.0.8.0)
>> Replaces:   cairo-dock-plugin-data,
>>    cairo-dock-plugins,
>>    cairo-dock-alsamixer-plugin,
>>    cairo-dock-animated-icons-plugin,
>>    cairo-dock-cairo-penguin-plugin,
>>    cairo-dock-clipper-plugin,
>>    cairo-dock-clock-plugin,
>>    cairo-dock-compiz-icon-plugin,
>>    cairo-dock-dbus-plugin,
>>    cairo-dock-desklet-rendering-plugin,
>>    cairo-dock-dialog-rendering-plugin,
>>    cairo-dock-drop-indicator-plugin,
>>    cairo-dock-dustbin-plugin,
>> ....
>>
>> NAK.
>> Most users do not need all plugin.
>> We should leave the choice that user can install only necessary plugin.
>> cairo-dock-plug-ins is a meta package of that purpose.
>>
>> Best regards,
>>  Nobuhiro
>> --
>> Nobuhiro Iwamatsu
>>    iwamatsu at {nigauri.org / debian.org}
>>    GPG ID: 40AD1FA6
>>
>
>
> Yes we (the upstream) know but there is a lot of reasons to not split these
> plug-ins:
> * It's hard to maintain these deb packages (some plugins are available on
> Ubuntu and not on Debian, some plugins are unstable, some plugins require
> some other, some plugins can become unstable or the name can change, or some
> plugins can merged, etc.)

Yes, Maintenance of the packages is very hard work.
But we do not maintian package for oneself.
It is necessary we think about the thing of the user, and to make a package

[Matthieu Baerts (matttbe)]

Yes we understand why you do that (we guess that it's not only for the fun ;) ) but if it's harder for the user too, I think it's not a good solution.

As said Fabounet, we use the same architecture as many programs like Compiz but on Compiz there are not a package for each plugin.

[Nobuhiro Iwamatsu (iwamatsu)]

Hi,

2011/2/21 Matthieu Baerts <email address hidden>:
> Yes we understand why you do that (we guess that it's not only for the
> fun ;) ) but if it's harder for the user too, I think it's not a good
> solution.

Yes, I do not think that it is easy for all users to choose a package.

I think that the one where user can install all plugin is simple in the user
who does not understand what user should have chosen.

And the provides of this function is performed in cairo-dock-plug-ins.
However, all users may not be so.
the user read description of the packages well, and who can understand
which plugin is included in which package installs a package by
oneself and will delete it.

The method that you suggest can support only the former.
With the present package, I come by both support.
Which intends for all users whether it is a good thing?

>
> As said Fabounet, we use the same architecture as many programs like
> Compiz but on Compiz there are not a package for each plugin.
>

Compiz does not depend on the CPU architecture.
I depend on the hardware which a CPU working.
Please BTS when Compiz is the architecture except IA32 and amd64, and
there is a problem.
I seem to work in most architecture now at least.
  https://buildd.debian.org/status/package.php?p=compiz
# Of course I think that there are many problems.

Best regards,
  Nobuhiro

--
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6

[Matthieu Baerts (matttbe)]

Hi,

Yes, we understand that it can be interesting to split each plug-in and to have one package for one applet but we (the upstream) discourage to do that. Some plug-ins are needed to launch some other one (e.g.: DBus and all externals applets, Gnome applet, etc.).
It's just like Compiz: there is a core package and its library and theres are a lot of plug-ins. Of course you can uninstall some plug-ins but it's highly not recommended because some plug-ins are needed by some other one... And there is no packages for each plug-in... It's just what the upstream want to have :)
And if the user want to absolutely remove a few plug-ins he can also do it with a 'rm' command... But just like splitting each plug-in in a lot of packages, we don't recommend to do that :-/

[Micah Gersten (micahg)]

I've remilestoned this for beta 1 (Sept 1) since this is not an FTBFS issue.

[Matthieu Baerts (matttbe)]

@Micah Gersten, @Brian Murray, @Matthias Klose: I really want to fix this bug but it seems that Debian maintainers of Cairo-Dock packages do not want to apply patches from the upstream (in fact, the upstream wants that the Debian maintainers use current Ubuntu Cairo-Dock's packages.). So what can we do?

[Nobuhiro Iwamatsu (iwamatsu)]

Hi,

This problem is the problem that do not divide or devide a package.
This problem terminated once because Debian maintainer provided
cairo-dock-clock-plugin.
However, the same problem open again.
  https://bugs.launchpad.net/bugs/540648

Best regards,
  Nobuhiro

2011/7/13 Matthieu Baerts <email address hidden>:
> @Micah Gersten, @Brian Murray, @Matthias Klose: I really want to fix
> this bug but it seems that Debian maintainers of Cairo-Dock packages do
> not want to apply patches from the upstream (in fact, the upstream wants
> that the Debian maintainers use current Ubuntu Cairo-Dock's packages.).
> So what can we do?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/657564
>
> Title:
>  Duplicated package with cairo-dock-plugins (coming from Debian)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/cairo-dock-plug-ins/+bug/657564/+subscriptions
>

--
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6

[Jeremy Bícha (jbicha)]

Hi, I realize you have strong feelings about this, but please remember that Ubuntu is a Debian derivative. That means that packaging in Debian is upstream. Ideally, the packages would be as close as possible to reduce duplicate work.

Why are you continuing to maintain two different duplicate packages? Please just use the Debian name conventions and the old source package can be removed from the Ubuntu repositories.

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.

[Jeremy Bícha (jbicha)]

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. That functionality is now part of indicator-session.

[Fabounet (fabounet03)]

Hi,
Cairo-Dock does not depend on indicator-me, it only has a dependency to
libindicator.

Here is the complete list of dependencies (taken from the wiki):

   - For compiling:
   cmake make pkg-config gcc gettext build-essential
   - For the core:
   libxxf86vm-dev libxtst-dev libx11-dev libgtkglext1-dev
   libcurl4-gnutls-dev libcairo2-dev libgtk2.0-dev librsvg2-dev
   libdbus-glib-1-dev
   - For the plug-ins
   libdbusmenu-gtk-dev libasound2-dev libgnome-menu-dev libetpan-dev
   libxklavier-dev libwebkit-dev libexif-dev libvte-dev curl libzeitgeist-dev
   libido-0.1-dev libindicator-dev libsensors4-dev
   - Add libthunar-vfs-1-dev for old XCFE (< 4.6) or libgnomevfs2-dev for
   very old Gnome (< 2.20).

as you can see, it's a quite small list.
the last 2 are NOT needed, the are only used if found to compile the
xxx-integration plug-ins; if the libs are not found on run-time, the plug-in
is not loaded. This allow Cairo-Dock to seamlessly integrate into all the
desktops, without depending on them.

2011/8/24 Jeremy Bicha <email address hidden>

> 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. That functionality is now part of indicator-session.
>
> --
> You received this bug notification because you are a member of Cairo-
> Dock Team, which is subscribed to cairo-dock-plugins in Ubuntu.
> https://bugs.launchpad.net/bugs/657564
>
> Title:
> Duplicated package with cairo-dock-plugins (coming from Debian)
>
> Status in “cairo-dock-plug-ins” package in Ubuntu:
> In Progress
> Status in “cairo-dock-plugins” package in Ubuntu:
> In Progress
> Status in “cairo-dock-plug-ins” source package in Natty:
> In Progress
> Status in “cairo-dock-plugins” source package in Natty:
> In Progress
> Status in “cairo-dock-plug-ins” source package in Oneiric:
> In Progress
> Status in “cairo-dock-plugins” source package in Oneiric:
> In Progress
> Status in “cairo-dock-plugins” package in Debian:
> In Progress
>
> Bug description:
> Binary package hint: cairo-dock-plug-ins
>
> Hi,
>
> After syncing cairo-dock-plugin package from debian, we now have two
> time the same source in the archive. Please work with Debian to be
> able to merge the 2 packages, and have it only once.
>
> Thanks,
> Fabrice
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/cairo-dock-plug-ins/+bug/657564/+subscriptions
>
> _______________________________________________
> Mailing list: https://launchpad.net/~cairo-dock-team
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~cairo-dock-team
> More help : https://help.launchpad.net/ListHelp
>

[Fabounet (fabounet03)]

Hi again ^_^
I'll let Matttbe explain in details, but one of the main problems is the
dependencies.
the dependencies list of the Debian package is just ridiculous (see my
previous mail for the exact list -- by the way for the 2.4 upower has been
added).
this is a very big problem, as many people won't install a program that will
pull so many dependencies.

I don't even talk about the one-package-for-each-plug-in approach, since it
has finally been worked-around with the "cairo-dock" meta-package.

2011/8/24 Jeremy Bicha <email address hidden>

> Hi, I realize you have strong feelings about this, but please remember
> that Ubuntu is a Debian derivative. That means that packaging in Debian
> is upstream. Ideally, the packages would be as close as possible to
> reduce duplicate work.
>
> Why are you continuing to maintain two different duplicate packages?
> Please just use the Debian name conventions and the old source package
> can be removed from the Ubuntu repositories.
>
> 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.
>
> --
> You received this bug notification because you are a member of Cairo-
> Dock Team, which is subscribed to cairo-dock-plugins in Ubuntu.
> https://bugs.launchpad.net/bugs/657564
>
> Title:
> Duplicated package with cairo-dock-plugins (coming from Debian)
>
> Status in “cairo-dock-plug-ins” package in Ubuntu:
> In Progress
> Status in “cairo-dock-plugins” package in Ubuntu:
> In Progress
> Status in “cairo-dock-plug-ins” source package in Natty:
> In Progress
> Status in “cairo-dock-plugins” source package in Natty:
> In Progress
> Status in “cairo-dock-plug-ins” source package in Oneiric:
> In Progress
> Status in “cairo-dock-plugins” source package in Oneiric:
> In Progress
> Status in “cairo-dock-plugins” package in Debian:
> In Progress
>
> Bug description:
> Binary package hint: cairo-dock-plug-ins
>
> Hi,
>
> After syncing cairo-dock-plugin package from debian, we now have two
> time the same source in the archive. Please work with Debian to be
> able to merge the 2 packages, and have it only once.
>
> Thanks,
> Fabrice
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/cairo-dock-plug-ins/+bug/657564/+subscriptions
>
> _______________________________________________
> Mailing list: https://launchpad.net/~cairo-dock-team
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~cairo-dock-team
> More help : https://help.launchpad.net/ListHelp
>

[Jeremy Bícha (jbicha)]

It does depend on indicator-me:

http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/oneiric/cairo-dock-plug-ins/oneiric/view/head:/debian/control#L83

[Jeremy Bícha (jbicha)]

You last pushed a new build of cairo-dock-plug-ins less than 2 weeks ago. 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. If you need help, you can ask here or in #ubuntu-motu among other places.

You're making a big deal about Debian depending on packages you don't. Which wrong dependencies are these?

[Matthias Klose (doko)]

I don't see a reason not to use the debian package as a basis.

 - the -integration package from plug-ins could be added as a delta in the
   ubuntu package. You could add similar dependency packages for other
   use cases.

 - If a dependency is not absolutely required, then make them a recommendation
   or a suggestion.

That leaves the case, where ubuntu is a version ahead of debian, and the burden of maintaining the separately packaged plugins is left to the ubuntu uploader.

So please make up a choice, maybe bring it to the technical board, or else I'll roll the dice and remove one package before the oneiric release ;)

[Fabounet (fabounet03)]

does "recommend" means it will be installed with the package ?
I know I've once disabled some option like that for apt-get.
anyway, the dock doesn't need it, so we should probably move it to "suggest"
(and add the zeitgeist daemon at the same time)

2011/8/24 Jeremy Bicha <email address hidden>

> It does depend on indicator-me:
>
> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/oneiric/cairo-dock-
> plug-ins/oneiric/view/head:/debian/control#L83
>
> --
> You received this bug notification because you are a member of Cairo-
> Dock Team, which is subscribed to cairo-dock-plugins in Ubuntu.
> https://bugs.launchpad.net/bugs/657564
>
> Title:
> Duplicated package with cairo-dock-plugins (coming from Debian)
>
> Status in “cairo-dock-plug-ins” package in Ubuntu:
> In Progress
> Status in “cairo-dock-plugins” package in Ubuntu:
> In Progress
> Status in “cairo-dock-plug-ins” source package in Natty:
> In Progress
> Status in “cairo-dock-plugins” source package in Natty:
> In Progress
> Status in “cairo-dock-plug-ins” source package in Oneiric:
> In Progress
> Status in “cairo-dock-plugins” source package in Oneiric:
> In Progress
> Status in “cairo-dock-plugins” package in Debian:
> In Progress
>
> Bug description:
> Binary package hint: cairo-dock-plug-ins
>
> Hi,
>
> After syncing cairo-dock-plugin package from debian, we now have two
> time the same source in the archive. Please work with Debian to be
> able to merge the 2 packages, and have it only once.
>
> Thanks,
> Fabrice
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/cairo-dock-plug-ins/+bug/657564/+subscriptions
>
> _______________________________________________
> Mailing list: https://launchpad.net/~cairo-dock-team
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~cairo-dock-team
> More help : https://help.launchpad.net/ListHelp
>

[Fabounet (fabounet03)]

well as you can see on the Debian packages site, the plug-ins depend on XFCE
and Gnome
we already said many times that this is wrong (the dock does not need any
desktop dependencies, at all)
cairo-dock is desktop -agnostic, and that's done through integration
plug-ins that are dynamically loaded, or not, at run time.

I'm not against having a common package (although I dislike the multitude of
packages for each plug-in, especially when some plug-ins are necessary to
get a correct user experience).
but then the Debian packager needs to upgrade to 2.4 and to listen to the
devs.

2011/8/24 Matthias Klose <email address hidden>

> I don't see a reason not to use the debian package as a basis.
>
> - the -integration package from plug-ins could be added as a delta in the
> ubuntu package. You could add similar dependency packages for other
> use cases.
>
> - If a dependency is not absolutely required, then make them a
> recommendation
> or a suggestion.
>
> That leaves the case, where ubuntu is a version ahead of debian, and the
> burden of maintaining the separately packaged plugins is left to the
> ubuntu uploader.
>
> So please make up a choice, maybe bring it to the technical board, or
> else I'll roll the dice and remove one package before the oneiric
> release ;)
>
> --
> You received this bug notification because you are a member of Cairo-
> Dock Team, which is subscribed to cairo-dock-plugins in Ubuntu.
> https://bugs.launchpad.net/bugs/657564
>
> Title:
> Duplicated package with cairo-dock-plugins (coming from Debian)
>
> Status in “cairo-dock-plug-ins” package in Ubuntu:
> In Progress
> Status in “cairo-dock-plugins” package in Ubuntu:
> In Progress
> Status in “cairo-dock-plug-ins” source package in Natty:
> In Progress
> Status in “cairo-dock-plugins” source package in Natty:
> In Progress
> Status in “cairo-dock-plug-ins” source package in Oneiric:
> In Progress
> Status in “cairo-dock-plugins” source package in Oneiric:
> In Progress
> Status in “cairo-dock-plugins” package in Debian:
> In Progress
>
> Bug description:
> Binary package hint: cairo-dock-plug-ins
>
> Hi,
>
> After syncing cairo-dock-plugin package from debian, we now have two
> time the same source in the archive. Please work with Debian to be
> able to merge the 2 packages, and have it only once.
>
> Thanks,
> Fabrice
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/cairo-dock-plug-ins/+bug/657564/+subscriptions
>
> _______________________________________________
> Mailing list: https://launchpad.net/~cairo-dock-team
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~cairo-dock-team
> More help : https://help.launchpad.net/ListHelp
>

[Matthieu Baerts (matttbe)]

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...

[Nobuhiro Iwamatsu (iwamatsu)]

Hi,

Sorry, answer is too late...

2011/8/31 Matthieu Baerts <email address hidden>:
> 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).

This was a change for package checks of Debian (lintian).

>  - 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....

We have not forced it on you about this.
This is a correction to have only in Debian.

>  - 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?

Hmm? We have not provided cairo-dock-data package.
We will change it like that if you want to divide it as cairo-dock-data package.

> * 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 up stream was cairo-dock-plugins. We only just use it.
If you need , I will change.

>  - 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)

I recommend that you change major and minor of soname if API is added,
and movement changes.
I cannot change these.

>  - 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.)

Because there is a user doing various how to use in Debian, I do
packaging so that many users are easy to use it.
I explain this by a former email.

>  - A few files are missing (e.g. for our DBus plugin)

Please bug report.

>  - 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 t...

[Matthieu Baerts (matttbe)]

Hello Nobuhiro Iwamatsu,

Thank you for your answer!

> This was a change for package checks of Debian (lintian).

Can you explain why it's a problem? I guess you're right and it's maybe not a good idea to use this tild character right there but we want to fix this bug for all users ;)

> We have not forced it on you about this.
> This is a correction to have only in Debian.

Yes, as I said, it's not a problem to change anything (BTW thank you to check our code and test it carefully!) but don't hesitate to report these changes, questions or bugs to us ;)

> Hmm? We have not provided cairo-dock-data package.
> We will change it like that if you want to divide it as cairo-dock-data package.

No it's not a big deal. It's just because Cairo-Dock packages have been created first for Ubuntu (it was a choice of a former contributor, sorry for that) and it seems the packages have been totally rewritten and we don't know why.

> The up stream was cairo-dock-plugins. We only just use it.
> If you need , I will change.

It's maybe a good idea to fix this bug. But as I said, I understand this choice 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.. (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493736)

> Because there is a user doing various how to use in Debian, I do
> packaging so that many users are easy to use it.
> I explain this by a former email.

We understand and we respect your opinion but we strongly discourage packagers from doing that...

> Sorry, where did you report this bug?
> At least I was not able to find it in Debian.

I know it was not the right place to do that but you said 'I see' (comment 11) so I guessed it was ok for you => https://bugs.launchpad.net/cairo-dock-plug-ins/+bug/540648
(except that you said 'せん' (No?) on the same line but I don't know why)

To conclude, thank you to maintain these packages but if you want, I can propose to you a new version of these packages with the same settings as Cairo-Dock packages for Ubuntu (7 packages) but ported to Debian.

[Michael Terry (mterry)]

Debian has renamed this to plug-ins (rather than plugins)

[Michael Terry (mterry)]

Archive admins, can you please remove cairo-dock-plugins from precise? It's no longer needed and has also been removed from Debian testing/unstable.

cairo-dock-plug-ins is now the source name in both Debian and Ubuntu.

[Michael Terry (mterry)]

Closing cairo-dock-plug-ins task, since there's nothing to do there.

[Martin Pitt (pitti)]

2011-12-02 09:42:59 INFO Removing candidates:
2011-12-02 09:42:59 INFO cairo-dock-plugins 2.3.0~3-2 in precise
2011-12-02 09:42:59 INFO Removed-by: Martin Pitt
2011-12-02 09:42:59 INFO Comment: renamed to cairo-dock-plug-ins
2011-12-02 09:43:00 INFO 1 package successfully removed.

[Colin Watson (cjwatson)]

I've unsubscribed ubuntu-archive, since there isn't any outstanding action requested of us on this bug (and in any case we're unlikely to remove packages from stable releases). Feel free to resubscribe us if and when there's a clear action for us to take.

[dino99 (9d9)]

https://wiki.ubuntu.com/Releases