Control: clone -1 -2
Control: tag -1 + pending
Control: retitle -2 dman: Should support manpages.ubuntu.com as well
Control: severity -2 wishlist
Control: submitter -2 Dustin Kirkland <kirkl...@ubuntu.com>
Hi,
Antoine Beaupré wrote:
> On 2017-05-01 14:33:56, Axel Beckert wrote:
> >> It appears that this is the right way to create directories:
> >>
> >> mktemp -d -t dman.XXXXXX
> >
> > Nope. The mktemp man page says about "-t": "interpret TEMPLATE as a
> > single file name component, relative to a directory: $TMPDIR".
> >
> > So I'll likely go with "-p" instead: "interpret TEMPLATE relative to
> > DIR; if DIR is not specified, use $TMPDIR if set, else /tmp. With this
> > option, TEMPLATE must not be an absolute name; unlike with -t,
> > TEMPLATE may contain slashes, but mktemp creates only the final
> > component"
>
> Quite frankly, at this point, I'm getting dangerously close to my "100
> lines maximum for shell scripts" rule (86 lines).
I'm sorry, but the bugfix for this bug (#861586: stores temporary
files in the current directory) is a change in a single line, no
additions at all:
-mandir=`mktemp -d dman.XXXXXX`
+mandir=`mktemp --tmpdir="${TMPDIR:-/tmp}" -d dman.XXXXXX`
(--tmpdir and -p are equivalent, but --tmpdir is IMHO the more clear
variant.)
Will push that patch soon.
The remainder of that thread is no more about this bug report but
mainly about supporting manpages.ubuntu.com as well. Hence I'm cloning
this bug report accordingly. Setting Dustin Kirkland (Cc'ed) as
submitter for that cloned bug report as he brought up that topic first
on https://github.com/Debian/debiman/issues/57#issuecomment-298084362.
> With Ubuntu support coming, I really wonder if we shouldn't rewrite
> this in a proper language (e.g. python or go) that doesn't have
> those kind of idiosyncracies:
>
> https://github.com/Debian/debiman/issues/57#issuecomment-298235767
JFTR: This patch would add a dependency on lsb-release.
> When we get to string interpolation through eval is pretty much where I
> give up on shell anyways. ;)
Agreed. My personal preference for that would be Perl, though. So
don't expect me to patch that much if it's going to be Go or Python.
But JFS seems to understand and code Python quite well, so there would
be someone in the debian-goodies team who can do more than just fix
obvious issues in Python code.
With Go, we'd add the problem of statically compiled binaries and the
need to rebuild the package upon every build-dependency upodate. Not
to mention the switch of debian-goodies from Arch:all to Arch:any.
I really want to avoid such issues in debian-goodies and hence would
object to adding Go code to the debian-goodies package.
If someone wants to maintain dman in Go, C, C++ or any other compiled
language, please do so in a separate package. (In that casew, I'd
happily remove dman from debian-goodies and add an according
Recommends and/or add update-alternatives in that case.)
> That said, the agreement we had was to patch man.c instead of doing
> this, originally, so maybe it's a bad idea to do a rewrite at this
> stage...
Now that sounds like a horribly ugly idea. Reminds me of that joke
where grep also lists results from Amazon.
Regards, Axel
--
,''`. | Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
