cdrtools DEPENDS on supersed, so it can use the -i option in the ebuild. ie. cp Defaults.linux Defaults.linux.orig sed -e "s:/opt/schily:/usr:g" < Defaults.linux.orig > Defaults.linux becomes with supersed: sed -i "s:/opt/schily:/usr:g" Defaults.linux Is this really nescesary? A grep turned up only this ebuild doing this. Maybe I am picky, but I really dont want an ebuild replacing my standard sed with something special, just for that. (and dont try and unmerge supersed afterwards, or you will be screwed :) A package should have dependancies, not the ebuild! (and I did the above replacement, aced the supersed requirement, and got clean diffs on the binaries. If I am missing a real dependancy in cdrtools on supersed, then I am sorry.) Perhaps supsersed should be the default system sed; but that is a different discussion. Also, I wonder if the supersed ebuild shouldnt install as 'ssed', to avoid clobbering the system default sed and man page? Paul
So? You should be glad it does so! The original sed hasn't been updated in five years, despite many issues still outstanding. Supersed resolves these issues while providing extra functionality.
Strangely, however, I am not glad that a core system utility with known behaviour is gratuitously overwritten for little obvious gain. If you think that supersed is a clean superset of seds functionality, and fixes bugs in sed, then you can make an argument to replace sed with it. This ebuild does _not_ justify it alone. If someone thinks supersed is all that an a bad of chips, they should lobby to have it installed as the default, not sneak it into some random ebuild. Paul
I would tend to agree with Paul. I don't like overwriting POSIX utilities with some (possibly) less mature replacements. For that matter, I don't like one package overwriting another package's files, that's all. Perhaps we should install 'supersed' as /usr/bin/supersed, and not as /usr/bin/sed? For one, a quick glance already revealed a documentation bug in supersed's manpage: the <sarcasm>much needed</sarcasm> "-i" option is not documented. ;^) But is seems that this issue is worth opening a separate bug report. The fact that the original 'sed' has not been updated in a while may be due to a fact that it's a rather stable utility. If you want to use Perl regular expressions and "-i", you can always use: perl -pi -e 's:foo:bar:' to achieve the same effect. And no, I don't think that the redundant convenience in the only line in the ebuild justifies overwriting /usr/bin/sed on the system. But I've been noticing this tendency in more than one ebuild, so the problem is not limited to 'cdrtools'.
After futher looking at the ebuild and the source package, I cannot see why the bit of sed is needed at all. It looks like the file sed is modifying is used by the packages 'make install', but the ebuild doesnt make use of this, and hand places everything. It tests fine for me without the DEPEND and sed line. Paul
from my impression in my own testing and from the author and other users, supersed is supposed to drop in seamlessly as a replacement for GNU/sed. It will, in fact, become GNU/sed-4.x Anyway, supersed is now installing itself as /bin/ssed instead. Also, I agree with you that the ebuild really does not need that line sed'd anyway, but Arcady is the expert on that, so bouncing that particular issue to him.
Paul, you seem to be right that the Defaults.linux file is not used. However, there is a slight chance that the make system is trying to compile in run-time linker path or something like that (although under linux it is not done with "-R" option). I have no time to wade through the cascading makefiles right now to verify that. Filtering the defaults file through sed is not going to do any harm, so I've modified it to use the regular 'sed', and got rid of the supersed dependency. Thanks.
