FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 12-19-2009, 07:12 PM
Ben Hutchings
 
Default Bug#560786: gdb: Please make the python dependency optional

On Sun, 2009-12-20 at 03:30 +1030, Ron wrote:
> Hi Daniel,
>
> On Sun, Dec 13, 2009 at 09:34:53PM -0500, Daniel Jacobowitz wrote:
> > tags 560786 + wontfix
> > thanks
> >
> > On Sat, Dec 12, 2009 at 08:22:12PM +1030, Ron wrote:
> > > Not all machines that it's useful to be able to run gdb on
> > > also need or want python installed. Can we please make this
> > > extra dependency optional?
> >
> > No, we can't. You build GDB either with or without linking to Python.
> > I don't see a reason to split the GDB package into two and double its
> > archive size for this.
>
> I do appreciate, and share, your concern for not bloating the archive
> needlessly, but my concern is balancing that against the needs of small
> Debian systems, where the extra deps this drags in are of themselves a
> quite substantial and needless extra bloat. They are considerably larger
> than gdb is itself, and needing to put extra flash on a board, just to
> install python, which the board itself will never use, hits a much harder
> limit than an extra 4MB package in the archive would.
[...]

Why would you install gdb on a (non-development) system, rather than a
gdb stub?

Ben.

--
Ben Hutchings
Humans are not rational beings; they are rationalising beings.
 
Old 12-19-2009, 08:55 PM
Ron
 
Default Bug#560786: gdb: Please make the python dependency optional

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. 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.
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.

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 ...)?

If I'm wrong, I'll have learned something cool though, which would be
win-win enough for me

Cheers,
Ron



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-19-2009, 10:15 PM
Ben Hutchings
 
Default Bug#560786: gdb: Please make the python dependency optional

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?

> 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. I think that's
just tough luck. If another more important package grows that might
also force you to throw out gdb.

> 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.

> 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.

Ben.

> If I'm wrong, I'll have learned something cool though, which would be
> win-win enough for me

--
Ben Hutchings
Humans are not rational beings; they are rationalising beings.
 
Old 12-19-2009, 11:47 PM
Ron
 
Default 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



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-20-2009, 01:26 AM
Ben Hutchings
 
Default Bug#560786: gdb: Please make the python dependency optional

On Sun, 2009-12-20 at 11:17 +1030, Ron wrote:
[...]
> 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?

What you're missing is that gdb's scripting facilities were pathetic,
and Python integration finally fixes that.

Ben.

--
Ben Hutchings
Humans are not rational beings; they are rationalising beings.
 
Old 12-20-2009, 02:07 AM
Jonathan Yu
 
Default Bug#560786: gdb: Please make the python dependency optional

Ben:

On Sat, Dec 19, 2009 at 9:26 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
> On Sun, 2009-12-20 at 11:17 +1030, Ron wrote:
> [...]
>> 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?
>
> What you're missing is that gdb's scripting facilities were pathetic,
> and Python integration finally fixes that.
While that's nice to know, I personally don't script Python and
wouldn't want to have to install it on a restricted environment just
for a feature I don't use. It's paying for a feature that isn't
necessary, so I understand Ron's frustration here.

Ideally, this sounds like something that should be fixed in
coordination with upstream -- perhaps asking if they could dynamically
load Python libraries so as to use the feature if the right stuff is
available, or otherwise fall back without increasing the requirements
of the gdb package.
>
> Ben.
>
> --
> Ben Hutchings
> Humans are not rational beings; they are rationalising beings.
>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-20-2009, 08:40 AM
Ron
 
Default Bug#560786: gdb: Please make the python dependency optional

On Sun, Dec 20, 2009 at 02:26:53AM +0000, Ben Hutchings wrote:
> On Sun, 2009-12-20 at 11:17 +1030, Ron wrote:
> [...]
> > 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?
>
> What you're missing is that gdb's scripting facilities were pathetic,
> and Python integration finally fixes that.

Nothing I've requested or suggested will do anything to take that away
from you though. On the contrary, if this really is a useful feature,
then I fully expect other people will want to add scripting facilities
in all of the popular dialects. And I think that would be great.

Debian should have the most powerful tools that we are able to build
for it. But we also have a long tradition of resolving conflicting
needs by putting choice back in the hands of users.

You've put a case for a certain minority class of users, I've put a case
for another. And they are clearly orthogonal, excepting that they both
use some subset of features in gdb, so neither diminishes the validity of
the other. I'm offering to support the case I see as being important, so
the question that's really important is what is the best way to do that?

I can send Daniel a patch to provide a minimal build from the same source,
or I can maintain it independently if it's a burden he doesn't want to
carry. Or I can do something different if people have better ideas.

I don't see what is so troublesome about that, it's how Debian works when
it's working at its best. People who need things share their work on that
with others that also need it.

Daniel, sorry for the flood, just let me know which way you'd prefer to go.

Cheers,
Ron



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-20-2009, 09:45 AM
Eduard Bloch
 
Default Bug#560786: gdb: Please make the python dependency optional

#include <hallo.h>
* Ben Hutchings [Sun, Dec 20 2009, 02:26:53AM]:
> On Sun, 2009-12-20 at 11:17 +1030, Ron wrote:
> [...]
> > 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?
>
> What you're missing is that gdb's scripting facilities were pathetic,
> and Python integration finally fixes that.

And people who don't care shouldn't be forced against their will.

Why don't we provide a gdb-tiny package, in the same fashion as
vim-tiny? Or is the python support that much hardcoded into gdb source
now that it can never separated?

Regards,
Eduard.
 
Old 12-21-2009, 10:18 PM
Daniel Jacobowitz
 
Default Bug#560786: gdb: Please make the python dependency optional

Picking some arbitrary messages in this thread to respond to.

On Sun, Dec 20, 2009 at 03:30:20AM +1030, Ron wrote:
> I do appreciate, and share, your concern for not bloating the archive
> needlessly, but my concern is balancing that against the needs of small
> Debian systems, where the extra deps this drags in are of themselves a
> quite substantial and needless extra bloat. They are considerably larger
> than gdb is itself, and needing to put extra flash on a board, just to
> install python, which the board itself will never use, hits a much harder
> limit than an extra 4MB package in the archive would.

There is not just one GDB package in the archive. Many platforms have
two, and the build logic is tricky enough to produce all the variants
already... I really don't see the justification for another binary.

You've already said you don't have the space for GDB+Python. So file
a wishlist bug to split gdbserver out to its own package, and I'll do
that for you happily. Then you don't need to put the detached debug
info files on your target either. If you are putting them on your
target, well, that explains why you can't fit GDB!

> Ideally this should really be some sort of runtime dependency, otherwise
> what happens when people also add perl, lua, ruby, etc. etc. bindings to
> do the same thing as this python dep does?

It's not going to happen. We (the GDB developers) spent a long time
picking one language under the firm plan that we wanted exactly one.
We don't want to fragment available GDB scripts by language; that
defeats the point of making it scriptable.

> - libgdb-dev appears to be unused, and itself recommends that it never
> should be. That's the size of 2 gdb .debs itself, so if you really
> want to remain "archive neutral", we could trade it for a gdb-minimal
> package, and wind up using less archive space in the deal.

It exists for the benefit of the Free Pascal IDE. Also, it takes
almost no additional build daemon time.

> I've cc'd -devel, as others may have even better or simpler solutions,
> but I'd appreciate your guidance on the best way to move forward with
> solving this from here.

I just don't see why a solution to this is necessary in the archive.
Nothing you've said has changed that. Either we install gdbserver, or
else you can just throw a GDB binary around from system to system.
I don't think the range of systems which don't need and can't fit
Python, but can fit a GDB executable (and its substantial RAM
requirements, and the huge debuginfo files it needs to be useful)
is very large.

Remote debugging is easy, and this is exactly what it's for.

On Sun, Dec 20, 2009 at 11:45:00AM +0100, Eduard Bloch wrote:
> And people who don't care shouldn't be forced against their will.

I am not holding a gun to your head and making you install GDB.
I don't think this is an appropriate description. Debian isn't
in the business of providing every possible combination of configure
options; there are some other distros with that philosophy.

Didn't there used to be a statement in policy or the developer's
reference that optional dependencies should generally be enabled,
which had some special words about X11? I can't find it any more.

> Why don't we provide a gdb-tiny package, in the same fashion as
> vim-tiny? Or is the python support that much hardcoded into gdb source
> now that it can never separated?

It can be separated.

--
Daniel Jacobowitz
CodeSourcery


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-10-2010, 07:36 AM
Ron
 
Default Bug#560786: gdb: Please make the python dependency optional

Ok, let's see ...

On Mon, Dec 21, 2009 at 06:18:18PM -0500, Daniel Jacobowitz wrote:
> On Sun, Dec 20, 2009 at 03:30:20AM +1030, Ron wrote:
> > I do appreciate, and share, your concern for not bloating the archive
> > needlessly, but my concern is balancing that against the needs of small
> > Debian systems, where the extra deps this drags in are of themselves a
> > quite substantial and needless extra bloat. They are considerably larger
> > than gdb is itself, and needing to put extra flash on a board, just to
> > install python, which the board itself will never use, hits a much harder
> > limit than an extra 4MB package in the archive would.
>
> There is not just one GDB package in the archive. Many platforms have
> two, and the build logic is tricky enough to produce all the variants
> already... I really don't see the justification for another binary.

Well I offered to provide a patch -- so I can put in some work to help
simplify the build logic too, if that's the pound of flesh this will
cost me

> You've already said you don't have the space for GDB+Python. So file
> a wishlist bug to split gdbserver out to its own package, and I'll do
> that for you happily.

I haven't seen anyone object to that idea yet, so we seem to have a
rough consensus that would be a good plan independently of any other
issues here, yeah.

> Then you don't need to put the detached debug
> info files on your target either. If you are putting them on your
> target, well, that explains why you can't fit GDB!

"If I didn't have all that data which was actually useful to me, then
I'd have plenty of space for whole subsystems I will never need ;?"
That's probably not the most productive argument we could entertain

But seriously, it's about resource budgeting. When we design a new
product, we need to build in some slack space to allow for natural
growth and "incidentals". So if we have to build in slack space for
python, then $omebody has to pay for that. Because real memory costs
real money. And chances are, that somebody, will actually be you.
Because we'll have sold our stuff to someone who sells you stuff ...
Now eventually, memory will be so plentiful and cheap that we can just
waste it on any old thing, but in the meantime we're still a few years
from that point yet.

That's my issue. That's why I need "optional" things to stay optional.
Because when some other major tool decides to drag in ruby (or whatever)
for the same sort of extra fizz gdb gets from this, I need to be able
to tell one of you "thanks, but I don't need that today". What I don't
need to hear is "oh but it was ok for gdb" from the other guys ...

If I can do that with python here. ie. it becomes a Recommends or so,
then I'm totally happy. I think ;


> > Ideally this should really be some sort of runtime dependency, otherwise
> > what happens when people also add perl, lua, ruby, etc. etc. bindings to
> > do the same thing as this python dep does?
>
> It's not going to happen. We (the GDB developers) spent a long time
> picking one language under the firm plan that we wanted exactly one.
> We don't want to fragment available GDB scripts by language; that
> defeats the point of making it scriptable.

That seems like a rather risky edict/assumption to make... people
really do love their favourite languages. But hypothetical talk
about egdb springing up is way off the issue I'm concerned with
right now, so I'm happy to steer clear of bringing this into it
any further


> > - libgdb-dev appears to be unused, and itself recommends that it never
> > should be. That's the size of 2 gdb .debs itself, so if you really
> > want to remain "archive neutral", we could trade it for a gdb-minimal
> > package, and wind up using less archive space in the deal.
>
> It exists for the benefit of the Free Pascal IDE. Also, it takes
> almost no additional build daemon time.

Ok. If it's still needed, that's mostly what I was wondering.
Surely we can also do the "takes almost no additional buildd time" trick
with --without-python though, no? It looked like only a couple of files
would get touched by that at all. Did I miss something there?

Either way, this isn't like an extra OOo build we're asking for.

> > I've cc'd -devel, as others may have even better or simpler solutions,
> > but I'd appreciate your guidance on the best way to move forward with
> > solving this from here.
>
> I just don't see why a solution to this is necessary in the archive.
> Nothing you've said has changed that. Either we install gdbserver, or
> else you can just throw a GDB binary around from system to system.
> I don't think the range of systems which don't need and can't fit
> Python, but can fit a GDB executable (and its substantial RAM
> requirements, and the huge debuginfo files it needs to be useful)
> is very large.
>
> Remote debugging is easy, and this is exactly what it's for.

The range of systems is however larger than what gdbserver is suitable
for, by its own description. Yes, it's a useful tool, for some problems,
but it's not a magic bullet, without any cost of its own.

GDB and `gdbserver' communicate via either a serial line or a TCP
connection, using the standard GDB remote serial protocol.

_Warning:_ `gdbserver' does not have any built-in security. Do
not run `gdbserver' connected to any public network; a GDB
connection to `gdbserver' provides access to the target system
with the same privileges as the user running `gdbserver'.

There's a whole class of devices that's not really going to work for.
If I have to add another UART for it, we probably should just sell
you the memory.

Of the ones that brought this to light, I've no shortage of RAM,
but that doesn't make me reflexively want to waste on flash.
In some stages of development, the above restriction wouldn't really
be a problem in practice. In others it would be a clear dealbreaker.

This isn't the One True Solution. But I don't deny it's a good and
powerful one where it is most suitable to use.


> On Sun, Dec 20, 2009 at 11:45:00AM +0100, Eduard Bloch wrote:
> > And people who don't care shouldn't be forced against their will.
>
> I am not holding a gun to your head and making you install GDB.
> I don't think this is an appropriate description. Debian isn't
> in the business of providing every possible combination of configure
> options; there are some other distros with that philosophy.

We're equally not talking every possible combination here though.
Just the useful ones. And I think I can see one more than you
could before the start of this. (which I hope you're starting to
see now too

> Didn't there used to be a statement in policy or the developer's
> reference that optional dependencies should generally be enabled,
> which had some special words about X11? I can't find it any more.

I have a vague sense of what you are remembering, but common sense
should basically sum it up. Is there no way upstream would accept
doing this as a runtime plugin, that only gets used if it's there?

If not, I have enough of a need for this (from time to time), to
put in the work to do it however it needs to be done. For me the
essence of Debian is sharing work that would otherwise have to be
replicated, and I'm pretty sure I'm not the only one that will be
happy to have this. My cultivated laziness of course wants this
done in the simplest way possible for all involved, so I would
much rather help tweak your package to support it, if we can
agree on what payola we'll get for what costs ...

Best,
Ron



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 06:10 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org