Alexander E. Patrakov wrote:
Which of the following types of notes are considered stopgap solutions?
What's the proper place for each one in the released book (one of: the
main package page, Locale-Related Issues page, Wiki)?
I'm not completely up to speed on all of the locale issues. What
follows is my opinion only, for what I think is the right thing to do,
without knowing a bit about how much work is involved to get this done
before release.
IMO, we should put it all out there, right up front for everyone to see!
All known problematic packages should be mentioned on the Locale
Related Issues page, including the reverse problems like ROX breakage in
an 8-bit locale (if it were in the book). We should warn the users
before they get too far, only to find out that they have to change plans
halfway through.
The local related issues page is the perfect place to put in a big
warning before a user goes and does something that is not easily
reversible. It's also the place to let users know that Linux OSs in
general, are in a state of transition but heading in the right
direction. A list of links to the affected packages' pages should work
well to give users a heads up, but it should also continue to warn that
it's not all inclusive. "These are just the packages we know about."
Lastly, while still on the locale issues page, I'm not qualified to
write the text, but I'd like to see some specific examples of the types
of problems that may be seen, along with a short paragraph or two about
the adoption of UTF-8 and it's use in other distro's as an example to
prove (or disprove) it's future. I can see that this page would be very
valuable WRT education.
1) "This package simply doesn't work in multibyte locales, don't use it
or downgrade to 8-bit locale. There is nothing functionally equivalent
in BLFS or beyond, so no other solution exists"
Mention, with warning tags, immediately after the package description.
2) "This subcomponent of a package doesn't work correctly in multibyte
locales (e.g.: printing from Vim), but the rest of the package works
very well"
Mention, with note tags, immediately after the package description.
3) "This package needs horrible workarounds, like post-processing the
output with a perl script, in order to produce the correct result"
Mention, with warning tags, immediately after the package description,
and point to the wiki for a workaround.
4) "This package simply doesn't work in multibyte locales, but there is
a nearly equivalent replacement in the book"
Mention, with note tags, immediately after the package description, and
link to a well behaved package.
5) "This package simply doesn't work in multibyte locales, but there is
a nearly equivalent replacement beyond BLFS"
Mention, with note tags, immediately after the package description, and
link to instructions in hints, wiki, or just to the package homepage if
there isn't a complete set of instructions available (or interest/time
to write a set).
6) "This package needs upgrading to a development version"
Mention, with note tags, immediately after the package description. If
the instructions are unchanged for the development version, provide a
link to the development version download and state that the existing
instructions work fine, else link to the wiki with instructions (if they
are available).
7) "This package needs a big patch that makes it work in both 8-bit and
multibyte locales"
Assuming that the patch does not affect 8-bit locales, the patch should
be put in the book unconditionally.
8) "This package has a patch available, but it breaks functionality in
8-bit locales"
Mention, with note tags, immediately after the package description. If
there is no change in the build procedure, say so and link to the patch
citing it as optional and warning that it breaks 8-bit, else point to
the wiki (if instructions are available there).
9) "This package needs one extra line added to its default configuration
file"
Again, if it doesn't affect the normal build, then it should go in
unconditionally. If it does affect 8-bit locales, then wrap the single
instruction in note tags before the configure or before the make/make
install. If this means breaking screen tags, then it means breaking
screen tags.
10) [example: ROX Filer, if it were in the book] "This package authors
deliberately break functionality in non-UTF-8 locales. Don't use this
package in such locales"
Mention, with warning tags, immediately after the package description.
If a patch exists to make it work in 8-bit locales, then make mention of
it, though I doubt that this will ever be the case.
Again, I'll repeat that I'm not very well informed as to how much work
is involved to get the above done as I've suggested. Time permitting,
this is how I think that BLFS should handle the locale related issues.
-- DJ Lucas
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
