Re: Bug#560786: gdb: Please make the python dependency optional
Python does seem a very poor choice for this kind of application, given the traditional bloat of a python installation, but I suppose they've made their decision... -Miles -- "... The revolution will be no re-run brothers; The revolution will be live." -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#560786: gdb: Please make the python dependency optional
On Sun, Jan 10, 2010 at 07:06:05PM +1030, Ron wrote: > > 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. I'm working on this. I'll see what the build time costs of a gdb-minimal are at the same time (it's still pretty large). I still find your arguments unconvincing, but I may as well measure the cost of the compromise. > > 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 :) You can make strawman arguments at me as long as you want to. I'm quite familiar with resource-constrained systems - I work in the embedded industry. There are several ways to avoid keeping debug info files on your target system, and still recover traces or conduct debug sessions. At work, we advise all our customers to use stripped target filesystems. > 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? No, you have to reconfigure GDB from scratch to disable it. It's probably possible to change this, but it'd be fragile; I don't think it's a good idea. > 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. FYI, if you have any way to run GDB on your target, you have a way to run gdbserver. For instance, you can multiplex it over a single serial console. I agree there's complex setup involved. > 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? I have no idea. It would be a big pain to implement. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: 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 suit
Re: 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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#560786: gdb: Please make the python dependency optional
#include * 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. signature.asc Description: Digital signature
Re: Bug#560786: gdb: Please make the python dependency optional
On Sun, Dec 20, 2009 at 02:26:53AM +, 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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#560786: gdb: Please make the python dependency optional
Ben: On Sat, Dec 19, 2009 at 9:26 PM, 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. 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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: 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. signature.asc Description: This is a digitally signed message part
Re: Bug#560786: gdb: Please make the python dependency optional
On Sat, Dec 19, 2009 at 11:15:14PM +, Ben Hutchings wrote: > On Sun, 2009-12-20 at 08:25 +1030, Ron wrote: > > On Sat, Dec 19, 2009 at 08:12:44PM +, 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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: 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 +, 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. signature.asc Description: This is a digitally signed message part
Re: Bug#560786: gdb: Please make the python dependency optional
On Sat, Dec 19, 2009 at 08:12:44PM +, 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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: 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. signature.asc Description: This is a digitally signed message part
Re: Bug#560786: gdb: Please make the python dependency optional
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. 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? If that can't be done, then we do have precedent with things like vim, for providing both a -minimal and a -with-the-lot package for people. Anyhow, I'm serious about wanting/needing developer support for these sort of systems, so the main question is how Debian is going to provide that best. Other options I see right now are: - 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. - I ITP a separate package, that just removes the --with-python option passed to configure. That's my least favourite option in terms of bloat, but if the issue is that you don't _want_ to maintain this extra package yourself, then I can appreciate that, and am prepared to do that work myself rather than having it foisted upon you by the TC or similar. I'd really rather just send you a patch that does this from the same source package though, but whether it is worth my time to do that, depends on the detailed rationale for your making this wontfix. Simply removing the python dep is a much more trivial change if I have to go that way to resolve this. 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. Thanks, Ron -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
