Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 222439 - doman should support foo.lang.N filenames
Summary: doman should support foo.lang.N filenames
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Enhancement/Feature Requests (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Portage team
Keywords: InVCS
Depends on:
Blocks: 233213
  Show dependency tree
Reported: 2008-05-16 21:16 UTC by Yuri Vasilevski (RETIRED)
Modified: 2008-10-13 19:45 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---

doman-langsufix.patch (doman-langsufix.patch,832 bytes, patch)
2008-05-16 21:17 UTC, Yuri Vasilevski (RETIRED)
Details | Diff
doman-langsufix.patch (doman-langsufix.patch,880 bytes, patch)
2008-05-26 17:55 UTC, Yuri Vasilevski (RETIRED)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Yuri Vasilevski (RETIRED) gentoo-dev 2008-05-16 21:16:26 UTC
There are some packages that build manpages suffixed with the language codes like foo.1,

I would like "doman" to handle this situation as I think this scheme is quite reasonable and not so uncommon, specially since debian's debhelper has support for it. An currently there is no pleasant way to deal with this situation as "doman -i18n=lang" is not flexible enough to dial with a directory full of man pages in different languages.

Reproducible: Always

Steps to Reproduce:
Comment 1 Yuri Vasilevski (RETIRED) gentoo-dev 2008-05-16 21:17:13 UTC
Created attachment 153375 [details, diff]

A patch for doman that will handle the following cases (the same ones dh_installman can handle):
foo.1    -> man/man1/foo.1
foo.lang.1 -> man/lang/man1/foo.1

where ${lang} can be a two letter language code (ej: 'es') or a two letter language code followed by a variant (ej: 'es_MX').
Comment 2 SpanKY gentoo-dev 2008-05-17 03:21:53 UTC
please do not use string replacements like that ... too much of a possibility of hitting false positives

add a case to trim the lang from the end of the name only
Comment 3 Yuri Vasilevski (RETIRED) gentoo-dev 2008-05-19 15:52:28 UTC
(In reply to comment #2)
> please do not use string replacements like that ... too much of a possibility
> of hitting false positives

I think in this case the string replacement is reasonably safe, as I match for \.xx(_XX)?\. and man pages are not allowed to have dots in their names. But You are right, ${x/.${manlang}./.} or maybe ${x/.${manlang}.${suffix}/.${suffix}} is a lot safer (Note: bash's string substitution '.' matches only '.'), so I'll update the patch to that.

> add a case to trim the lang from the end of the name only

Sorry I don't get what do you mean by that case, could you please elaborate some more or give me an example?

PS: I'll update the patch once the second part of the request is clear to avoid spamming bugzilla.
Comment 4 SpanKY gentoo-dev 2008-05-22 01:51:01 UTC
what i meant was to use the % operator so that you only trim from the end of the string ... i think some of the code there is already doing similar stuff
Comment 5 Yuri Vasilevski (RETIRED) gentoo-dev 2008-05-26 17:55:50 UTC
Created attachment 154375 [details, diff]

Updated patch as requested by SpanKY.
Comment 6 Zac Medico gentoo-dev 2008-05-27 23:10:54 UTC
Thanks, I've just committed a version of your patch which makes use of bash's =~ operator and corresponding $BASH_REMATCH array:

-	mandir=${i18n}man${suffix:0:1}
+	if [[ $x =~ (.*)\.([a-z][a-z](_[A-Z][A-Z])?)\.(.*) ]] ; then
+		name=${BASH_REMATCH[1]##*/}.${BASH_REMATCH[4]}
+		mandir=${BASH_REMATCH[2]}/man${suffix:0:1}
+	else
+		name=${x##*/}
+		mandir=${i18n}man${suffix:0:1}
+	fi
Comment 7 SpanKY gentoo-dev 2008-05-31 05:51:56 UTC
i'd suggest we avoid the =~ operator as it historically breaks during bash upgrades ... but hopefully most of that has finished now that =~ has been out for a while ...
Comment 8 Zac Medico gentoo-dev 2008-05-31 18:45:10 UTC
That crossed my mind too. However, that's not the only thing that can break with a bash upgrade. Something like bug 190128 could also happen again. It's not the end of the world if something breaks like that (hopefully it won't though). If any kind of severe breakage occurs, we'll have to do like we did for bug 190128 and use blockers to prevent bad combinations of portage & bash. Blockers like those aren't nearly as annoying as they used to be, since current versions of portage can solve them automatically by adjusting merge order (upgrade portage first, then bash).
Comment 9 Marius Mauch (RETIRED) gentoo-dev 2008-06-10 16:08:23 UTC
Fixed in or before 2.2_pre8