On 7/15/05, Steve Langasek <[EMAIL PROTECTED]> wrote: > On Fri, Jul 15, 2005 at 05:30:44PM +0900, Junichi Uekawa wrote: > > An alternate solution is to have a database for that kind of thing, > > but I forsee that it requires effort to maintain and keep up-to-date. > > Like the database I just queried above? :)
There's an even better one called "Google". If you're adding a library dependency to a package that you plan to maintain for the benefit of a large number of users, you might want to know a little more about the library, its upstream, and its packager than just what the relationship is between foo.sf.net, foo-X.X.tgz, and the binary package names. Automated tools, on the other hand, can and should be primed with data, not heuristics. Test suites _should_ be fragile so that if something changes in a remotely questionable way you _spot_ it. Then you use a heuristic, if available, to update the priming data and touch it up manually where necessary. Automate where it helps, not where it hurts. > > It's rather embarassing to know that Debian isn't organized at all in this > > manner. Organization is overrated. While good code is, in the long run, an aesthetic criterion as much as anything else, some aesthetic instincts can be misleading. Cathedral / bazaar, and all that. (Though I personally prefer cathedrals, and if you've read about how they were actually built, you will see that the Linux, glibc, GCC, perl, python, etc. development process looks much more like cathedral building than like the Kasbah.) > You seem to be embarrassed easily. If this is such a problem for using > Debian as a development platform, why is this the first time I've seen the > subject discussed on debian-devel? There may well be useful tools that are made harder to write by the indiscriminate naming of packages. For an example where the global aesthetic criterion does tend to win, at the expense of some use cases, consider the prejudice against splitting off "micro-packages" to slim down the dependencies of the main binary package. tetex-bin comes to mind -- and don't tell me that tetex-base is the main package, because it's tetex-bin that is needed when building X11 (last time I checked; still true of xfree86 in unstable; apparently also true of xorg). Perhaps it's not worth splitting out xpdf as a separate source package to break the circular build-depends -- although it would avoid gratuitous security updates to the rest of tetex. But I for one really don't like having to have the binary packages from an old xfree86 build installed in order to do a new build. Yeah, you can build your own tetex-bin with xpdf excluded, or just force-install tetex-bin without the X libs in a chroot -- but it's ugly. I know that the package count is getting to be a scalability problem and that people are working on ways of dealing with that, and in the meantime there is some rational pressure not to split packages needlessly. I'm not blaming the TeTeX team for weighing the factors and deciding not to split. I'm just giving an example of a warning sign that too many meanings are being overloaded onto one technical distinction -- in this case, the boundaries of a .deb. Another example would be localization packages; I hope I don't need to spell that one out. > I'm not convinced that the problem you're trying to solve is of sufficiently > general interest to outweigh all of the other problems it introduces (such > as the ones that have been pointed out in this thread). IMHO the problem is real, the solution is wrong. Don't try to organize the underlying data; add enough metadata markup that you can present better organized views for various purposes. Don't rush to add that metadata to debian/control; sketch out a heuristic using existing metadata that leaves you with a relatively small number of manual overrides, write real applications that use it, and then decide if it's OK to keep the manual overrides as detached metadata or if they belong in debian/control. Cheers, - Michael