Re: Feaping Creature-ism in core Debian Packages
In article <[🔎] Pine.LNX.3.96.990901071450.1387B-100000@dwarf.polaris.net> you wrote:
> On 31 Aug 1999, Manoj Srivastava wrote:
> The maintainer may not even
> have been aware that they stepped ouside the boundries of the essential
> perl package, and thus will not know to include this dependency in any
> future source depends mechanism.
Am I missing something? I thought that's why we had a bug tracking system. I
have indeed done exactly this, using a perl feature that wasn't in perl-base
in a postinst, and it took all of a half day for a bug to get filed about
it, and another day for me to notice the bug and fix it. What's the big deal?
> Actually the problem that I ran into with make (which started me down this
> trail) was that it requires texi2html, which comes from the tetex-bin
> package, which requires xlib6g from the xfree86 package. It was this
> dependence of a core package on a large applications package that began to
> cause my skin to itch.
Yes, it sucks. However, I've now helped to jump-start three non-i386 ports
for Debian (sparc, alpha, and arm), and it's just part of the game. I am sure
that on arm there were at one point at least 3 packages that I just used the
top-level upstream makefile to do a 'make ; make install' kind of thing on,
totally ignoring the debian/rules file. That got me enough working
executables to get over the hump that I was facing.
Frankly, I think the issues involved in a cold-metal bootstrap are sufficiently
uncommon that forcing all of our source packages to be automatically buildable
for such an environment as a matter of policy would be an over-reaction.
> Until we have elaborated source dependency issues we are vulnerable to a
> catastrophic pathology in source dependencies. I don't think that it is
> too early to begin considering the issues.
They are routinely being handled for all but the cold iron bootstrap case by
the various folks involved in managing the platform autobuilders. None of the
things you have run in to are particularly newsworthy.
> I can comment out those calls in the rules file, and build a functional
> make package, but such "corrections" are not easy to work into an
> autobuild process. (Debian isn't just for Intel any more)
Please remember that there's a distinction between an autobuild process and
a bootstrap process.
> My point is that making individual packages "better" at the expense of the
> overall package integration process is _not_ the path to a superior
> distribution. We must begin to consider the ramifications of these
> individual improvements as they pertain to the "big picture", and not
> remain tightly focused solely on the optimization of individual packages.
Yes. On this point we agree.
The problem with a "rapid prototype" like Debian is that when it gets put to
such wide use, it's hard to toss the prototype and replace it with something
of real, production quality. :-)
Bdale
Reply to: