Bug#764441: sinfo and slurm-client: error when trying to install together
Hi Gaudenz, thanks for the upload! On Sat, Oct 11, 2014 at 11:58:36PM +0200, Gaudenz Steinlin wrote: But I would still like to hear from the slurm maintainers and from I personally agree with Mehdi about the fact that it's too late to find a stable name in time for Jessie and confirm our will to find a better solution for the next release. Best regards, -- Gennaro Oliva -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764441: sinfo and slurm-client: error when trying to install together
Control: reassign 764441 sinfo Control: fixed 764441 0.0.47-2 Le 2014-10-11 23:58, Gaudenz Steinlin a écrit : Hi Mehdi Dogguy me...@dogguy.org writes: Le 2014-10-09 22:55, Gaudenz Steinlin a écrit : I will certainly update the Conflict if we can't agree on a better solution in the next few days. But as the Conflict was a workaround from the begining I'd prefer a solution where we agree on different names for the commands instead. I very much agree with what you say, but I think it is rather late to find a stable name (where also upstream is confortable with) in time for Jessie. There are only a few days left before the freeze. For that reason, I prefer to keep the old (and not so nice) workaround and work on a better solution to implement in Jessie+1. I've now uploaded a package with the conflict updated to slurm-client. Thanks. This is very much appreciated! (and marked as such) Besides, please note that you should still conflict with the old binary package name to support partial upgrades. But I would still like to hear from the slurm maintainers and from Jürgen Rinas (sinfo upstream and Debian co-maintainer) about the possibility of renaming one of the commands. I would still very much prefer that solution. What is the meaning of sinfo in the context of tool for monitoring computer clusters using broadcasts? Regards, -- Mehdi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764441: sinfo and slurm-client: error when trying to install together
Hi Mehdi Dogguy me...@dogguy.org writes: Control: reassign 764441 sinfo Control: fixed 764441 0.0.47-2 Le 2014-10-11 23:58, Gaudenz Steinlin a écrit : Hi Mehdi Dogguy me...@dogguy.org writes: Le 2014-10-09 22:55, Gaudenz Steinlin a écrit : I will certainly update the Conflict if we can't agree on a better solution in the next few days. But as the Conflict was a workaround from the begining I'd prefer a solution where we agree on different names for the commands instead. I very much agree with what you say, but I think it is rather late to find a stable name (where also upstream is confortable with) in time for Jessie. There are only a few days left before the freeze. For that reason, I prefer to keep the old (and not so nice) workaround and work on a better solution to implement in Jessie+1. I've now uploaded a package with the conflict updated to slurm-client. Thanks. This is very much appreciated! (and marked as such) Besides, please note that you should still conflict with the old binary package name to support partial upgrades. Just to be sure and to not have to do yet another upload. Adding a conflict against slurm-llnl ( 14.03.8-1) would be right, as according to the slurm-llnl changelog that's the version where the packages were renamed. And wouldn't it be better to also add a conflict on the slurm-client side? This would at least prevent a similar bug if the package get's renamed again. But I would still like to hear from the slurm maintainers and from Jürgen Rinas (sinfo upstream and Debian co-maintainer) about the possibility of renaming one of the commands. I would still very much prefer that solution. What is the meaning of sinfo in the context of tool for monitoring computer clusters using broadcasts? I don't know the reasons why this package was named sinfo. Maybe Jürgen can answer this question. Gaudenz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764441: sinfo and slurm-client: error when trying to install together
Le 2014-10-12 22:59, Gaudenz Steinlin a écrit : Hi Mehdi Dogguy me...@dogguy.org writes: Control: reassign 764441 sinfo Control: fixed 764441 0.0.47-2 Le 2014-10-11 23:58, Gaudenz Steinlin a écrit : Hi Mehdi Dogguy me...@dogguy.org writes: Le 2014-10-09 22:55, Gaudenz Steinlin a écrit : I will certainly update the Conflict if we can't agree on a better solution in the next few days. But as the Conflict was a workaround from the begining I'd prefer a solution where we agree on different names for the commands instead. I very much agree with what you say, but I think it is rather late to find a stable name (where also upstream is confortable with) in time for Jessie. There are only a few days left before the freeze. For that reason, I prefer to keep the old (and not so nice) workaround and work on a better solution to implement in Jessie+1. I've now uploaded a package with the conflict updated to slurm-client. Thanks. This is very much appreciated! (and marked as such) Besides, please note that you should still conflict with the old binary package name to support partial upgrades. Just to be sure and to not have to do yet another upload. Adding a conflict against slurm-llnl ( 14.03.8-1) would be right, as according to the slurm-llnl changelog that's the version where the packages were renamed. IMHO, you can leave the conflicts statement on slurm-llnl unversioned as even the new one depends on slurm-client which brings sinfo. Otherwise, yes, 14.03.8-1 is the correct version. And wouldn't it be better to also add a conflict on the slurm-client side? This would at least prevent a similar bug if the package get's renamed again. We can do that. I'll first wait until it migrates to testing and then do a second upload adding that. Regards, -- Mehdi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764441: sinfo and slurm-client: error when trying to install together
Hi Mehdi Dogguy me...@dogguy.org writes: Le 2014-10-09 22:55, Gaudenz Steinlin a écrit : I will certainly update the Conflict if we can't agree on a better solution in the next few days. But as the Conflict was a workaround from the begining I'd prefer a solution where we agree on different names for the commands instead. I very much agree with what you say, but I think it is rather late to find a stable name (where also upstream is confortable with) in time for Jessie. There are only a few days left before the freeze. For that reason, I prefer to keep the old (and not so nice) workaround and work on a better solution to implement in Jessie+1. I've now uploaded a package with the conflict updated to slurm-client. But I would still like to hear from the slurm maintainers and from Jürgen Rinas (sinfo upstream and Debian co-maintainer) about the possibility of renameing one of the commands. I would still very much prefer that solution. Gaudenz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764441: sinfo and slurm-client: error when trying to install together
Le 2014-10-09 22:55, Gaudenz Steinlin a écrit : I will certainly update the Conflict if we can't agree on a better solution in the next few days. But as the Conflict was a workaround from the begining I'd prefer a solution where we agree on different names for the commands instead. I very much agree with what you say, but I think it is rather late to find a stable name (where also upstream is confortable with) in time for Jessie. There are only a few days left before the freeze. For that reason, I prefer to keep the old (and not so nice) workaround and work on a better solution to implement in Jessie+1. Regards, -- Mehdi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764441: sinfo and slurm-client: error when trying to install together
Hi Gaudenz, On Wed, Oct 08, 2014 at 10:34:45AM +0200, Gaudenz Steinlin gaud...@debian.org wrote: Ralf Treinen trei...@free.fr writes: Here is a list of files that are known to be shared by both packages (according to the Contents file for sid/amd64, which may be slightly out of sync): /usr/bin/sinfo /usr/share/man/man1/sinfo.1.gz This happends because the sinfo binary in slurm moved from slurm-llnl to slurm-client and now the conflict specified in sinfo is wrong. To restore the previous state, sinfo should update it's conflict to slurm-client with appropriate versioning. Since your package had a Conflicts, can you please update it? If you agree on that, can you also reassign this bug to src:sinfo so that it is tracked properly? Cheers. -- Mehdi Dogguy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764441: sinfo and slurm-client: error when trying to install together
Mehdi Dogguy me...@dogguy.org writes: Hi Gaudenz, On Wed, Oct 08, 2014 at 10:34:45AM +0200, Gaudenz Steinlin gaud...@debian.org wrote: Ralf Treinen trei...@free.fr writes: Here is a list of files that are known to be shared by both packages (according to the Contents file for sid/amd64, which may be slightly out of sync): /usr/bin/sinfo /usr/share/man/man1/sinfo.1.gz This happends because the sinfo binary in slurm moved from slurm-llnl to slurm-client and now the conflict specified in sinfo is wrong. To restore the previous state, sinfo should update it's conflict to slurm-client with appropriate versioning. Since your package had a Conflicts, can you please update it? If you agree on that, can you also reassign this bug to src:sinfo so that it is tracked properly? I will certainly update the Conflict if we can't agree on a better solution in the next few days. But as the Conflict was a workaround from the begining I'd prefer a solution where we agree on different names for the commands instead. The conflict is especially bad as the packages are not just two completely unrelated pieces of software but a cluster monitoring software and a cluster resource manager and job scheduler. I can very well imagine that people want to install both on the same system. Gaudenz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764441: sinfo and slurm-client: error when trying to install together
Package: slurm-client,sinfo Version: slurm-client/14.03.8-2 Version: sinfo/0.0.47-1+b1 Severity: serious User: trei...@debian.org Usertags: edos-file-overwrite Date: 2014-10-08 Architecture: amd64 Distribution: sid Hi, automatic installation tests of packages that share a file and at the same time do not conflict by their package dependency relationships has detected the following problem: Preconfiguring packages ... Selecting previously unselected package libgcrypt20:amd64. (Reading database ... 10872 files and directories currently installed.) Preparing to unpack .../libgcrypt20_1.6.2-4_amd64.deb ... Unpacking libgcrypt20:amd64 (1.6.2-4) ... Selecting previously unselected package libboost-signals1.55.0:amd64. Preparing to unpack .../libboost-signals1.55.0_1.55.0+dfsg-3_amd64.deb ... Unpacking libboost-signals1.55.0:amd64 (1.55.0+dfsg-3) ... Selecting previously unselected package libboost-system1.55.0:amd64. Preparing to unpack .../libboost-system1.55.0_1.55.0+dfsg-3_amd64.deb ... Unpacking libboost-system1.55.0:amd64 (1.55.0+dfsg-3) ... Selecting previously unselected package ucf. Preparing to unpack .../archives/ucf_3.0030_all.deb ... Moving old data out of the way Unpacking ucf (3.0030) ... Selecting previously unselected package sinfo. Preparing to unpack .../sinfo_0.0.47-1+b1_amd64.deb ... Unpacking sinfo (0.0.47-1+b1) ... Selecting previously unselected package libmunge2. Preparing to unpack .../libmunge2_0.5.11-1.1+b1_amd64.deb ... Unpacking libmunge2 (0.5.11-1.1+b1) ... Selecting previously unselected package munge. Preparing to unpack .../munge_0.5.11-1.1+b1_amd64.deb ... Unpacking munge (0.5.11-1.1+b1) ... Selecting previously unselected package slurm-client. Preparing to unpack .../slurm-client_14.03.8-2_amd64.deb ... Unpacking slurm-client (14.03.8-2) ... dpkg: error processing archive /var/cache/apt/archives/slurm-client_14.03.8-2_amd64.deb (--unpack): trying to overwrite '/usr/bin/sinfo', which is also in package sinfo 0.0.47-1+b1 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Processing triggers for man-db (2.7.0.2-1) ... Errors were encountered while processing: /var/cache/apt/archives/slurm-client_14.03.8-2_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) This is a serious bug as it makes installation fail, and violates sections 7.6.1 and 10.1 of the policy. An optimal solution would consist in only one of the packages installing that file, and renaming or removing the file in the other package. Depending on the circumstances you might also consider Replace relations or file diversions. If the conflicting situation cannot be resolved then, as a last resort, the two packages have to declare a mutual Conflict. Please take into account that Replaces, Conflicts and diversions should only be used when packages provide different implementations for the same functionality. Here is a list of files that are known to be shared by both packages (according to the Contents file for sid/amd64, which may be slightly out of sync): /usr/bin/sinfo /usr/share/man/man1/sinfo.1.gz This bug has been filed against both packages. If you, the maintainers of the two packages in question, have agreed on which of the packages will resolve the problem please reassign the bug to that package. You may then also register in the BTS that the other package is affected by the bug. -Ralf. PS: for more information about the detection of file overwrite errors of this kind see http://edos.debian.net/file-overwrites/. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764441: sinfo and slurm-client: error when trying to install together
Ralf Treinen trei...@free.fr writes: Here is a list of files that are known to be shared by both packages (according to the Contents file for sid/amd64, which may be slightly out of sync): /usr/bin/sinfo /usr/share/man/man1/sinfo.1.gz This happends because the sinfo binary in slurm moved from slurm-llnl to slurm-client and now the conflict specified in sinfo is wrong. To restore the previous state, sinfo should update it's conflict to slurm-client with appropriate versioning. A better solution would be if one of the binaries would be renamed. I don't know what the sinfo command in slurm does, so I can't judge if it's easy to rename or not. Renameing the sinfo command in the sinfo package would be suboptimal at best because it's the main command of this package. Gaudenz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
