On Mon, Oct 11, 2010 at 03:43:27AM +1100, Harshula wrote: > On Sat, 2010-10-09 at 13:14 -0700, Josh Triplett wrote: > > libm17n-0 recommends m17n-contrib and m17n-db, but does not give any > > indication of the functionality these packages provide for programs that > > use libm17n-0, making it difficult for a user to sensibly decide whether > > to install them. For instance, emacs23 depends on libm17n-0, and seems > > to work fine without these packages installed; what functionality of > > emacs23 would not work without installing these packages? > > > > In general, these packages don't seem like "packages that would be found > > together with this one in all but unusual installations". > > You've raised an interesting question. My initial reaction is Emacs > should Depend on both libm17n-0 and m17n-db. Emacs appears to use > libm17n and m17n-db for complex text layout. libm17n contains the C API > and m17n-db contains the layout rules. So without both packages Emacs > will not function correctly. For example, copy the following Sinhala > text "කොහොමද" into Emacs with both libm17n-0 and m17n-db installed. Take > a screenshot. Then remove m17n-db and copy the text into Emacs and see > the difference.
Interesting. It didn't make a difference with the default font I normally use in Emacs (Neep Alt), but with DejaVu Sans Mono the first character moved before the quote. Does that sound like the correct behavior? > The upstream developers decided to split external contributions to > m17n-db into m17n-contrib. However, my understanding is that they will > merge in the next major release. Good to know. > > Please consider documenting the reason a user might want to install > > these packages in libm17n-0's description, and please consider carefully > > whether these packages need a Recommends or whether a Suggests would > > suffice, particularly since Recommends get installed by default now. > > The relationship is either Recommends or Depends. Definitely not > Suggests. >From your explanation, it certainly sounds that way, and it sounds like a "Depends" to me. If a program uses libm17n, it expects to do text layout *correctly*, and if libm17n can't do that in general without an extra database, then that database represents a necessary component of the library, as much so as all the various libfoo-common packages floating around Debian. Making it a Recommends so people can save a few bytes by breaking text layout for languages more complex than English seems wrong; how would people even begin to figure out how to fix such a problem? Anyone who cares *that* much about space can use techniques like localepurge or dpkg exclusion and handle the corresponding breakage; meanwhile, packages in Debian should Just Work for their primary intended purpose. Does that sound reasonable? > Should a package's description contain explanations as to why > it Recommends other packages? Is that a requirement? Do other packages > already do this? Every time a package has a Recommends or Suggests instead of a Depends, the user may have to make a decision about whether to install the package or not. Many packages do include an explanation for their Recommends and Suggests to help the user make such a decision. For an extreme example, see devscripts; for a simpler case, see gnupg and gnupg-curl. > m17n-db description already contains: "This package contains the > database files used by m17n-lib." > > m17n-contrib description already contains: "This package contains the > database files contributed by the community and used by m17n-lib." "used by" doesn't say how, and more importantly doesn't answer the questions automatically raised by the use of Recommends rather than Suggests: "If foo doesn't have a Depends on bar, then how does foo manage to do without bar, or what can foo do with bar that it can't without, or what part of foo will break or lose functionality if I don't install bar?" So, if you decide not to use Depends, I'd suggest explicitly saying something like "libm17n requires m17n-db and m17n-contrib to handle languages with complex text layout requirements." But again, it seems questionable why someone would want to cripple m17n by not installing those packages. Similarly, someone *could* omit key pieces of emacs, such as major modes for uncommon languages, and put them in a separate package with a Recommends; however, those represent a sufficiently expected part of the functionality of emacs that they need a Depends-level "always installed" relationship. By contrast, gdm3 only Recommends xserver-xephyr, because it can use xephyr to implement the nested login functionality, but people wouldn't consider gdm3 *broken* without that functionality. - Josh Triplett -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
