On 07/04/2011 01:57 AM, Adam D. Barratt wrote: > On Mon, 2011-07-04 at 01:19 +0800, Thomas Goirand wrote: >> On 07/04/2011 12:15 AM, Jonathan Nieder wrote: >>> Or at least to add the Conflicts >>> to swift to prevent immediate breakage? >> >> Yes, and this should be also put into suckless-tools until this is solved. > > No, it shouldn't. Adding the Conflicts: to either package is a policy > violation, adding it to both doesn't improve things.
Did you read my sentence in full? I wrote *until this is solved*. I didn't write that declaring the issue with a Conflicts: was in anyway a fix, and I agree it it is a policy violation! My only point is that if there's a conflict, you should declare it asap until we can solve things. On 07/04/2011 02:08 AM, Jonathan Nieder wrote: > I was suggesting: > > 1) as a short-term measure, add a Conflicts to the swift package. This > doesn't improve its policy compliance, but it at least improves the > user experience a little. > > 2) before release time, rename "st" in swift upstream. I hope it's going to happen. It's up to us to monitor and push upstream to do so. > 3) in the meantime, keep this bug open so the package doesn't migrate > to testing. Right. > suckless-tools has nothing to do with it. :) If adding a Conflicts to > the suckless-tools package were needed, the same fix would be needed > in testing (and in stable in analagous cases) to support partial > upgrades. Luckily, it isn't needed. I'm wondering, and you still didn't reply my question: what is the use of "st" in suckless-tools? Is it a binary called by the user, or barely just launched by a script? My point here is that in Swift, "st" is a userland tool. So each time you'll see in the docs reference to it, which may be very annoying for our users. Is this the case with suckless-tools? Please reply to this very important point. Cheers, Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
