| Summary: | sys-apps/man unicode USE-flag to support UTF-8 locales | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Petr Polezhaev <NightNord> |
| Component: | New packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | enhancement | CC: | pacho |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
New man ebuild
Patch file ebuild: merged from this bug and #93664 Modified patch from bug #93664 comment #18 |
||
|
Description
Petr Polezhaev
2008-02-26 18:18:28 UTC
Created attachment 144687 [details]
New man ebuild
Adds unicode USE-flag support. I don't really sure, how it must be called - utf8 or unicode. Unicode is common, but applies for unicode support in common, utf8 used nowhere, but more right for only-utf8 support.
The second way is to convert to current locale, and supply only 'nls' flag, but this could make some misunderstand after basic system install.
*** This bug has been marked as a duplicate of bug 126361 *** No, this have nothing related to groff. This is related to internal messaging system. For example: $ LANG="C" man sdgsdg No manual entry for sdgsdg $ man asfasf ???? ???? ????? ????? Sorry, I must include this as an example, to prevent such misunderstanding... And sorry for bad English So attach a unified diff for the ebuild so that someone can actually review what's this bug about. Created attachment 144688 [details, diff]
Patch file
...
Ok. I have added what you want that is certainly never what we want to do. convert files inside of the program during runtime according to the locale, never during build time. what it fixes for you breaks for other people. *** This bug has been marked as a duplicate of bug 93664 *** OK, but this bug doesn't looks like soonly approved... So, as I say, it maybe will be better to mark this flag as 'utf8'. This USE flag. If you switch it on - so you want things done this way. This is: a) Simplier that realtime convertion b) More stable. c) Auto-convertion applies to _everyone_, so any bug will affect everyone. This way affect only utf8 users. Yes. This is not applied only for someone with locales like UTF-16/32, but there is no traslations for them. Otheres, who uses non-unicode locales, will possible match with default encoding, and they will _not_ switch this flag on. This idiology of uses - you want it - you switch it on, isn't it? It can be used as temporary solution, while auto-converting will be maked and tested. So, I don't understand, what _exactly_ will this break? the correct fix has already been proposed in the duplicate bug *** This bug has been marked as a duplicate of bug 93664 *** Oh yes? Provided, you say... Bug #93664 was opened at 2005-05-23... Now is... 2008-02-26! 3 years gone... Maybe it will be more wise to make _any_ temprorary solution even only for someone, that wait another 3 years, while it will be fixed at upstream (then tested - as it was mentoed above - this way affect everyone, so it need very good testing, before releasing)? Or we going to apply this patch without testing. Anyway: Bug #93664 Comment #18 : "Patch based on "fix garbage in man's messages"-patch + makefile-changes to convert catgets-files to utf8." So we will use unpermanent patches, which must be reviewed every version, while all of this can be done with ebuild? If you don't what to apply this hack solution - just merge this. Ebuild convertion to utf-8 + realtime convertion from utf-8 for non-unicode users. Or you want us to do this? ... i'm not interested in hacks *** This bug has been marked as a duplicate of bug 93664 *** Created attachment 144699 [details] ebuild: merged from this bug and #93664 Any converting, from Makefile, or from ebuild - is hack. If upstream will make catgets in UTF-8 in their next releases - this wouldn't be a hack. Any patches - also is hacks. But you are not doing anything to apply this patch, so I will do it for in way I think is better. There is a merged ebuild that uses ebuild-script to utf8 convertion, and applies modified patch for runtime convertion from Bug #93664 comment #18. Created attachment 144701 [details, diff] Modified patch from bug #93664 comment #18 I'm not interested in what you interested. All this done not for you, maybe you even hasn't such problem. Want you hacks or not - this is a core utilite, with bug stucked for 3 years, which affect all non-english-speaking users... What are you waiting for? Working patch was created in year 2006, why it isn't in tree? Because it's not your problem, it's upstream problem? This is problem of your users, who needs to use the same hack, but apply it manually from update to update. *** This bug has been marked as a duplicate of bug 93664 *** No, no, no... You can't just redirect this bug, without answering. Anyway, this is just rude, not to answer. Futhermore, it's rude not to read, what someone traying to say you. It's hard for me to write even a few lines on English, so I spend my time just for providing some arguments for you, but you even not listen. This is bad way of dialogue. Ok, ok, you are busy man, with many users and own work, but... Let's see comment from 'man''s maintainer ( Bug #93664 #13 ), especially: "The established community process is to notify the maintainer (which he did) for the final, solid fix (which takes longer), and introduce a distro-fix until he releases the final one." If you not want to listen me, listen man who mantains this program - they don't hurry with bugfix, because think, that everyone who wants already done some temporary bugfix. And this is normal. Think about your users! They want to have normal utilite, without need of manipulating with some developer's utitlites and making some magic actions to make it work as it _should_ work. There is thousands of users, who uses man, and even don't know about such hack, as described in starting HOWTO. Why they need to search some solutions, while you have everything! You have patch, which was checked by man's mantainer. You have his advice, to make own fix, while upstream thinking. You even have ebuild realising this fix. If you don't like this ebuild, you can just append perfectlly working patch to existing ebuild and it will work! Why you are not doing anything? Why YOU are not interested?!! There is no 'you'. There is community. Community choosen you to serve it's interests, not your. If you are only man who can add this fix in tree, why you are betraying trust, which you have been granted? There is no users for portage, there is portage for users, and you, as one portage mantainer, must think about users, not about your some abstract ideas abount portage structure and code cleaning. Users want this bug to be fixed. Users even give you everything to fix it. You must just take it and put in portage tree and keep working while upstream fix it. So problem isn't in upstream or in portage or in patch, or ebuild, problem is in you. And you stopping this issue from beeing resolved. You go againsts your users, you go againsts maintainer of program this bugs relaying on, you go agains primitive logic. What do you think about yourself? there's nothing to answer. what you're complaining about is obviously a dupe of an already opened bug, thus it gets marked as a duplicate. this bug is dead, leave it alone and stop wasting time *** This bug has been marked as a duplicate of bug 93664 *** (In reply to comment #17) > No, no, no... You can't just redirect this bug, without answering. You have had your answer. You just didn't like it. Seriously, stop wasting our time. Night Nord, if you really want this bug fixed, contact upstream. Gentoo generally follows what upstream prepares. Also obviously this is duplicate of said bug because bug records *one issue and possible solutions*. But there is no sense in and it''s impossible to track additionally opened bugs for the same issue but with different solutions. *** Bug 214742 has been marked as a duplicate of this bug. *** |
