Re: Bug#560786: gdb: Please make the python dependency optional
On Sat, Dec 19, 2009 at 11:15:14PM +0000, Ben Hutchings wrote:
> On Sun, 2009-12-20 at 08:25 +1030, Ron wrote:
> > On Sat, Dec 19, 2009 at 08:12:44PM +0000, Ben Hutchings wrote:
> > > Why would you install gdb on a (non-development) system, rather than a
> > > gdb stub?
> >
> > Maybe I'm missing something cool and obvious here, but in the particular
> > case this came to my attention: simplicity?
> >
> > The device is amply endowed enough to comfortably run gdb on it directly,
> > and all I really needed gdb for was to get a backtrace from a single
> > failure.
>
> Without debug information?
Of course not. But building a debug version of something you are
debugging isn't exactly major surgery, and we do have the technology
for detached debug packages today.
Neither of those things is in the same league as needing to write a
low level gdb stub for a currently unsupported arch. For something
that should be a 3 minute job on a debian development system. Even
if you stop to sip coffee in the middle of it.
> > I don't really expect to need it again anymore for a while.
> > I've always considered the stubs to be for devices that _aren't_ powerful
> > enough to run gdb (or a minimal, but otherwise "out of the box" Debian
> > install for that matter). This one isn't _that_ small.
> >
> > What it doesn't have is mountains of desktop grade filesystem storage, so
> > filling that with interpreters for languages that will never be used on
> > it, doesn't really seem like the best use of customers hard earned dollars.
>
> What you seem to be saying is, gdb used to be small enough that you
> could squeeze it into a production image even though you didn't need it
> very often. And the new version of gdb breaks that.
No. What I'm saying is gdb is _still_ small enough to be directly useful,
but that it's now dragging in a ton of useless baggage, *much* larger than
its own size, that 99% or more of its users will probably never ever use.
And that this will only get worse if more bindings for optional interpreters
are ever added for it.
> I think that's just tough luck. If another more important package grows
> that might also force you to throw out gdb.
I'm not worried about the natural growth of important packages. What I
am distressed about is the gratuitous binding of important packages to
utterly irrelevant ones.
How many years do you think it will take for gdb itself to grow by the
amount that this totally worthless dependency chain adds to the system?
I do pity the sort of people who need to write python programs to debug
their other programs, but I really don't think that it's "just tough luck"
for everyone else to have to pay for their sins. It's not like it is
going to cost us a firstborn to limit that to just people who do need it.
> > And this doesn't really seem like an unusual device configuration for the
> > next 5 - 10 years or so. We really would rather just run Debian on it than
> > hack up yet another pseudo-distro because it wouldn't fit for silly reasons,
> > so I'd like to "not have to pay for things we don't need", to steal an idea
> > from the C++ folk.
>
> The gdb front-end is surely in the "things [you] don't need" category.
No, it's on the list of "things that will save me hours, days, or months,
on the rare occasions when I actually need it". And it already Just Works.
Why should I think going backward from that is some sort of progress?
We want bread. But we want Roses too.
> > Am I really missing something about the stubs that would make that easier,
> > or faster, or better, than apt-get install gdb, followed by "bt"? Because
> > then yeah, maybe my point here is moot. But my impression is it would be
> > a lot more work than that, and I don't see an arm stub at all, (and
> > gdbserver is in the gdb package ...)?
>
> That strongly suggests that gdbserver should be split into a separate
> package.
That may be. But that's a separate question to this one really.
I don't understand the pushback I'm getting on this. The bloat that was
already added _far_ outweighs the little extra it needs to fix it, and
that's before we save on pruning away libgdb. I don't think I'd be going
out on a limb to suggest this will be of benefit to far more people than
the number who'll need python scripts to use gdb. Am I?
Really, what am I missing here?
Confused now,
Ron
Reply to: