Hi:
Thank you for the responses Chmouel.
All the libraries - that was a lot of work/time/money! And now you've got
some bozo trying to second guess the decision of all the developers. * I do
apologize if it seems that way.* I am concerned about long term effects
but "convince us" is not a task that can be done by myself. You are the
magician and I am still, _once again_, a student learning to perform the new
tricks with aya OS.
When I suggested v.8.0 as a reinsertion point I did not realize _all_
libraries( - glibc ) had been stripped. How many megabytes does it actually
save to strip them?
I can/will/do use --debug as necessary but that does not help the end user
that gets the pop-ups of 'debug me and send bug report' and who actually
wants to help by doing that.
=>. If the libraries were not stripped would not the information sent to
KDE, Gnome, ...even MDK, be of greater value?
=>. Would not this make your job and the rest of the mdk developers jobs
easier/faster/cheaper to perform by using the library _and_ user resources
to improve KDE, etc... QA response?
=>. Would not this also result to make the development/QA cost of the mdk OS
less and thereby increase the profit margin?
=>. Would not that also buy you a café au lait or two? :)
( Ok, all of that is very simplified but still valid i think if the info in
the libraries was good enough to provide valuable debugging results. I don't
know since it's the 'chicken and the egg' here.)
Logic would dictate that increasing the quality of the debug information
would still be the desirable approach at this point in the development
process, and not stripping out what was already there.
=>. If space is not the only consideration ( " even if we had some place on
the disk we will not put library not stripped " ), what would be the other
reason(s) for stripping the libraries?
... and thanks again for listening, considering and responding.
Regards,
rj
Linux: Get it. Use it. Improve it.
=========================
----- Original Message -----
From: "Chmouel Boudjnah" <[EMAIL PROTECTED]>
To: "rj" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, February 15, 2001 11:21
Subject: Re: [Cooker] Stripped libraries
| "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
db.( 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
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
