"rj" <[EMAIL PROTECTED]> writes:
> As the beta cycle is imminent, could this process of stripping libraries of
> the 'extra' debugging information be discussed more in depth?
As you wish (we are really open in our company (private joke) ;))
> Most of the regular cookers probably know more about this than I, but this
> following reason for stripping libraries does not make any sense to me(or
> cent$ for me, either):
> " ...space... most of the end-users don't debug programs..."
> I do not understand why libraries get stripped and "xrally", "xpuzzels",
> "xpilot", 5+ email clients, 4+ shells, "BitchX", ... , etc. remain. The
> very experienced programmer may not need the additional debugging info but I
> have recently started programming again and need _any_ debugging help
> available and, btw, am one of those "end-users" that does run gdb.( icyw,
> those RPMS above are just _some _examples_ of what could be considered to be
> extra fluff ...nothing personal against them! )
The choice of programs is another subject there is more end-users that
want a choice to use some tools that end-users want to debug
binary. What i don't understand is why you don't do like us (mdk
developers) when there is some bugs just recompile with --debug the
programs.
> =>. Where is the need for so many 'choices' on the core disk at the expense
> of stripped libraries and, ultimately, our (developers' ) time?
The policy.. we do distribution for end-users... to debug and let the
others debug it just like normal with recompiling the buggy program.
> =>. Is anyone at M'Soft using the data from all those 'package' polls that
> have been running in the mandrakeforum for months? ( G', I hope this is not
> the result. )
Yes. QA and Product Marketing does it.
> =>. Will someone( Chmouel? Jean-loup? Whomever made the decision? ) please
> explain that "space" reasoning in the light of so many other programs that
> could be moved to another disk source to make room for the larger libraries?
The decision has been made by the core team of development in
agreement with others developers. even if we had some place on the
disk we will not put library not stripped.
> =>. Would you also tell us if there is an easy way to get the full libraries
> integrated?
--debug, but there is not actually we was thinking about doing some
lib-dbg package for some librariries but it gives some problems like
for gtk (dindin can you tell more about that).
> =>. At the very least, is there a list of which libraries and what got
> stripped?
everything (via spec-helper) except the glibc.
> In the end, I know that you cannot please all the people all the time...no
> matter how hard you try. I also know the M'Soft folks try very hard to do
> that anyway. :-) I'm only suggesting that, perhaps, making life easier for
> new/potential developers is in M'Soft's _and_ Linux best interest. Moving
> some programs off the core disc should be OK if it is to keep full libraries
> available _with_ all the debugging information intact. Certainly, even the
> person(s) that raised so much H! last year about "Why is joe missing" could
> understand and agree to such a reorganization. Version 8.0 is a good time
> to do it, is it not?
it's definitively not, and you have still have to convince us....
--
MandrakeSoft Inc http://www.chmouel.org
--Chmouel
