Red Hat Bugzilla – Bug 188156
fixps broken - tries to re-create directory
Last modified: 2007-11-30 17:11:29 EST
Description of problem: On my fc5 system, if I try to run a2ps with a postscript file, it will fail with a "mkdir: cannot create directory blah". I traced it down in fixps which is a bash script. This is the problem: On line 41: tmpdir=$(mktemp -d /tmp/$program.XXXXXX) On line 194: mkdir $tmpdir This will fail because mktemp already created the directory. Version-Release number of selected component (if applicable): a2ps-4.13b-49 How reproducible: /usr/bin/fixps -q /tmp/y.ps mkdir: cannot create directory `/tmp/fixps.k18151': File exists Additional info: Simple solution would be to change line 194 to mkdir -p
Confirmed. Why not just remove that mkdir call though? Seems to be superfluous given the behaviour of mktemp.
Sure, I guess I was looking for the safest fix. Removing that line should be just fine.
Strangely it is fixed in cvs, but not published in the devel repo?
Problems building it.. :-(
I think that the attached patch allows to rebuild. However I think it would be much simpler if the autotools weren't run. From a look at the patches, I can't see why it should be needed? Couldn't calling external libtool be sufficient? Or did I miss something?
Created attachment 136533 [details] patch to use AC_ variants instead of AM_ for newer autoconf
Thanks! Possibly it isn't needed any more, but at this stage we're really trying to stick to minimal changes..
I think it has never been needed, and it is more a little packaging mistake (although I cannot say for sure). I have spotted many issues in the a2ps package, it is not up-to-date with regard with the packaging guidelines and best practices -- like many packages in core. I have allready (and completly independently) filled a bug for the split of a -devel package, but I think filling many bugs for packaging issues is a lost of time. In my opinion to have more feedback and avoid time lost in following those many little packaging bugs it would be more practical and less time consuming if you just started a FC review bug, to help solving all the issues globally. Of course this is also a time consuming process, but unlike a classical review it is allready in core so you'll have all your time to fix things. This is for the devel branch only of course, for FC6 it is indeed better to keep things as they are.