[arch-dev-public] Removal of skill and snice from procps-ng
Hi, In the new 3.3.3 upstream update of procps-ng, the skill and snice utilities are no longer built by default. According to the man page: "These tools are obsolete and unportable. The command syntax is poorly defined. Consider using the killall, pkill, and pgrep commands instead." I would like to know if there are any objections in removing them from the procps-ng package and, more importantly, if there are any packages or scripts in the repos that use these tools. If so, we should create a TODO list to port them to using killall, pkill, and pgrep instead. We could also keep supplying these tools until upstream decides to remove them for good. Another way to handle this would be to include them but warn users with a post-install message and/or front page news that they will go away in the next procps-ng update. This way, everyone will be warned and will have enough time to update their packages and any custom scripts. That might be the best option especially if no one knows if there are used in packages or not. Eric
On Thu, May 24, 2012 at 08:40:44PM -0400, Eric Bélanger wrote:
Hi,
In the new 3.3.3 upstream update of procps-ng, the skill and snice utilities are no longer built by default. According to the man page: "These tools are obsolete and unportable. The command syntax is poorly defined. Consider using the killall, pkill, and pgrep commands instead."
I would like to know if there are any objections in removing them from the procps-ng package and, more importantly, if there are any packages or scripts in the repos that use these tools. If so, we should create a TODO list to port them to using killall, pkill, and pgrep instead. We could also keep supplying these tools until upstream decides to remove them for good.
Another way to handle this would be to include them but warn users with a post-install message and/or front page news that they will go away in the next procps-ng update. This way, everyone will be warned and will have enough time to update their packages and any custom scripts. That might be the best option especially if no one knows if there are used in packages or not.
Eric
+1 to dropping outright. Semi-related point of interest -- Redhat has been throwing around the idea of asking procps-ng to merge with util-linux. d
participants (2)
-
Dave Reisner
-
Eric Bélanger