Bug #222439 introduced the handling of localized manpages. While this is handy, the automatic detection of the language detection leads to bugs where the extension is not meant to be a locale. For example vdradmind.pl.1 which is a man page for a perl script and not the polish localisation.
i'm of the opinion that programs you run like `foo` in $PATH shouldnt have arbitrary suffixes like '.pl' or '.sh' or '.py'. people executing `foo` dont give two sh*ts about the implementation details.
(In reply to comment #1) > i'm of the opinion that programs you run like `foo` in $PATH shouldnt have > arbitrary suffixes like '.pl' or '.sh' or '.py'. people executing `foo` dont > give two sh*ts about the implementation details. > Agreed! In my case I already solved this by using newbin for the perl script and newman for the man page. If I remember right there are cases where the manpage is split up into parts like man.part1.1, man.part2.1 etc... I filed this bug because I have seen two cases where the automatic locale detection causes problems withing two days.
can you provide some other examples ? i'm not terribly sympathetic to .pl programs and such ...
(In reply to comment #3) > can you provide some other examples ? ld.so.8 > i'm not terribly sympathetic to .pl programs and such ... Right. But doman could still provide an escape mechanism, even if there are only few legitimate cases.
(In reply to comment #3) > can you provide some other examples ? i'm not terribly sympathetic to .pl > programs and such ... net-analyzer/dhcp_probe uses `doman doc/dhcp_probe.cf.5'. The man page ends up being installed as </usr/share/man/cf/man5/dhcp_probe.5.bz2>.
good enough for me ... thanks guys
So, what option letter should be used for this? -k (for "keep") -N (for --literal according to GNU coding style) Any better suggestions?
does `doman -i18n=` work today ?
(In reply to comment #8) > does `doman -i18n=` work today ? It's ignored if the filename contains a language suffix.
any reason for not fixing that behavior rather than adding new flags ?
Created attachment 222201 [details, diff] doman.patch (In reply to comment #10) > any reason for not fixing that behavior rather than adding new flags ? Good idea. We only have to make the -i18n option take priority, as in attached patch.
(In reply to comment #11) If we want to avoid having doman behave differently depending on the portage version, we'll have to make that behavior change conditional on a new EAPI.
Created attachment 222241 [details, diff] doman.patch (In reply to comment #12) > If we want to avoid having doman behave differently depending on the portage > version, we'll have to make that behavior change conditional on a new EAPI. Right, new patch for EAPI 4 (or later) is attached. So far PMS doesn't mention the option at all, in spite of all package managers supporting it. Patch will follow.
Created attachment 222243 [details, diff] Patch for PMS First attempt of a wording for PMS. This would be for EAPI 4.
(In reply to comment #14) > Created an attachment (id=222243) [details] > Patch for PMS > > First attempt of a wording for PMS. This would be for EAPI 4. Short review: * Is it really "the empty string" or "an empty string"? * write "e.\,g." * Better use "\t{-i18n=\textit{lang}}"
(In reply to comment #15) > * Is it really "the empty string" or "an empty string"? Since the empty string is unique I think "the" is correct here. > * write "e.\,g." "e.\,g.\" even, and the other dozen occurences of it should be fixed too. > * Better use "\t{-i18n=\textit{lang}}" You're right again, but I suggest that we postpone these typographical matters. (I haven't even looked at the LaTeX output yet. ;-)
We've used "in EAPIs specified by" rather than "in EAPIs as decided by" everywhere else I think. The latter sounds rather weird to me.
Created attachment 222257 [details, diff] Patch for PMS Updated patch, addressing the points of comment #15 and comment #17. I've also changed the wording slightly to avoid overfull lines in LaTeX output (due to the long directory names that cannot be split).
(In reply to comment #18) > Created an attachment (id=222257) [details] > Patch for PMS "Supports doman languages?" is a bit vague given that the -i18n option is supported in all EAPIs (I know it's worded like that already, and you didn't write it, but still...). Maybe something like "Supports doman language detection by filename?"
(In reply to comment #19) > "Supports doman languages?" is a bit vague given that the -i18n option is > supported in all EAPIs (I know it's worded like that already, and you didn't > write it, but still...). Maybe something like "Supports doman language > detection by filename?" Fine with me. I think I'll wait for a few days to collect any other suggestions, before preparing a new patch. Another question, should "newman" accept an -i18n option too (and propagate it to doman)? Currently it doesn't, but we could add this for EAPI 4.
(In reply to comment #19) > Maybe something like "Supports doman language detection by filename?" It turns out that this makes the table too wide. How about "Language detection by filename"?
(In reply to comment #21) > It turns out that this makes the table too wide. How about "Language detection > by filename"? > Sure. Just noticed that the caption says "EAPIs supporting doman languages", which should probably be changed for the same reason, although I can't think of what to change it to.
(In reply to comment #22) > Just noticed that the caption says "EAPIs supporting doman languages", which > should probably be changed for the same reason, although I can't think of > what to change it to. "\t{doman} language support for EAPIs"? (The i18n option is about language support too.)
(In reply to comment #23) > "\t{doman} language support for EAPIs"? > (The i18n option is about language support too.) > Maybe something about "options" or "extras", since the base -i18n is available in all of them, but something like that, yeah.
Created attachment 223393 [details, diff] Patch for PMS New patch, taking all comments into account.
This was approved for EAPI 4 in yesterday's council meeting. Portage implementation is tracked in bug 316311.
EAPI 4 has been approved by the council.