Re: shared library -dev package naming proposal
On 7/15/05, Steve Langasek <vorlon@debian.org> 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
Reply to: