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 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
Reply to: