Re: Linux sigtramp detection code moved to its proper place

[Eli Zaretskii <eliz at delorie dot com>]

>    How about i386linux-tdep.c, for example?
> 
> Yuck, that's ugly!

How is it uglier than i386gnu-nat.c?

> Is it really important that these Linux-specific files are correctly
> extracted on MS-DOS?  I believe your argument was about buggy tar
> programs floating around, but I don't think it is too much too ask
> people to fix their tar before trying to build GDB.

What would you suggest for a non-buggy Tar program to do, exactly?

Let's take GNU Tar, for example.  It specifically supports the case
where you can untar over an existing source tree, so it by default
silently overwrites existing files.  How can Tar tell whether the file
only *seems* to exist, due to the silent truncation of the long file
names by the OS?  I don't think it can, but I'd love to hear ideas.
(I spent lots of time making the DJGPP port of GNU Tar friendlier to
DOS/Windows systems, and solved many problems, but couldn't find any
good solution to this one.)

Sure, there are options such as --backup to take care of overwriting.
But you don't want to trust users to use non-default options, because
they will surely forget (and yours truly then gets to answer the FAQs
on comp.os.msdos.djgpp ;-).

Besides, --backup only prevents files from being overwritten, but it
still leaves it to the user to sort out the mess it left behind (by
deleting unneeded files, renaming needed ones, etc.).  How exactly do
we expect the user to know which files are needed and which aren't?

Also, --backup cannot help much when you are unpacking over an
existing tree.

Then there's DJTAR, supplied as part of the DJGPP development kit.
This makes a point of refusing to overwrite files (so it doesn't
support updating existing trees).  But it does so by prompting for a
new name for each file which seems to exist.  Try to unpack a distro
with a few dozens of such files, and reflect on the resulting
frustration...

In other words, a distribution which has too many files whose names
clash after truncation to 8+3 limits cannot in good faith claim that
it supports DJGPP.  And the goal of the DJGPP project is to have all
major GNU packages support DJGPP in their official distributions, to
prevent wasting effort on re-porting each release.