This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Add expat to the GDB sources


On Sun, Jul 23, 2006 at 11:20:04PM -0700, Joel Brobecker wrote:
>> Any UNIX-like system shipped within the last decade comes with a
>> decent curses implementation, wo we consider it to be a part of the
>> operating system.  Apart from Linux there are probably no systems that
>> ship with expat.  And even on most Linux systems expat won't be usable
>> because the bloody expat "development" package isn't installed.
>
>Plus: Having it in our source tree allows us to have a good knowledge
>and control of what we have. What if a user has a whather-distro-modified
>version of libexpat and this version has a big bug in it? Or what if
>the current released version has a bug that we just fixed? I think
>not having it in our tree makes it more difficult for our users
>to build GDB, and that should also count.

You can make similar statements about any of the libraries which gdb
uses, like ncurses or glibc.  And, you can flip it around, too.  Distros
are apt to fix bugs when they are detected.  Are we going to have someone
scanning bugtraq, the expat web site, and the
Fedora/Gentoo/Ubuntu/Debian web sites looking for updates?

>I don't want to make a policy of it, but having something as small
>as libexpat, especially since it doesn't seem to be evolving much,
>seems better than documenting the requirement of having it installed
>on the system.

So, if expat is small and not evolving it is not apt to have a big bug
in it...

>So even thought we should make a decision on a case by case basis,
>I would be inclined in this case to include libexpat. I don't think
>we're actually doing a fork. I think it's like readline: we try to
>push the patch to the authors first before putting it in our copy.

But readline has been a fork for a long time and, since it is statically
compiled into gdb, we don't see the benefit of the readline shared
library, we don't see any improvements in new distro releases, and we
need to use gdb manpower resources to keep it up-to-date.

There is also the meta issue here of assuming that gdb owns the 'src'
directory and has the right to put things there without discussion with
the other projects who use the directory.  IMO, the polite thing to do is
to mention this to the other projects.

cgf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]