This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc 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: Latest Glibc from CVS has segmentation problems.


Marcus Brinkmann <marcus.brinkmann@ruhr-uni-bochum.de> writes:

> I am hopeful that if somebody would make a serious effort to guide
> newbies around glibc, we could get him to say something like
> "www.glibc-for-newbies.com", which is shorter.  When there is no such
> effort, however, the best advise to give lost people is to not bother
> trying, so they know that they are on their own.

I would like to see such an effort as well, but that is really beside
the point.  Other free software projects do not often have such
independent "for newbies" efforts, and they mostly avoid telling end
users to get lost.

> One easy thing would be to ask, in a new thread, and without
> prejudice, "What must happen or be done before a release can be
> done, and is there any way I can help with that?".

I began by asking a simple question without prejudice:

  http://sources.redhat.com/ml/libc-alpha/2004-03/msg00051.html

> Such a question might still be ignored, however, because usually
> release schedules are not discussed with "random people".

Yes, it was ignored, just like similar questions from others in the
past.

> Usually, software is released if you want to get people to use a
> particular version of the software.  With glibc, things are in so
> far different as it is _always_ included in _all_ distributions, and
> you can't simply update it.  It's quite unlike an application
> software package.

This is no different than the kernel, yet somehow Linux manages point
releases more than once a year.

A release does more than get people to use a particular version.  A
release provides a baseline from which third parties can operate.  It
provides a common point of reference for things like bug reports,
known bugs/fixes, compilation advice, special-purpose patches, and so
forth.

Without a reasonably up-to-date release, individuals and smaller
distribution makers are at a disadvantage, because they do not have
the resources to create all of these things in-house based on some
randomly chosen CVS checkout.

If the glibc project does not care about individuals and smaller
distribution makers, then its Web pages ought to make that clear and
save us some time.

> Nothing stops you from making your own glibc releases from CVS
> versions and release them under version names similar to Alan Cox's
> experimental Linux kernels.  Maybe by doing that you will find your
> own reasons why glibc is not released officially at this stage...

This is essentially what I am doing, but within the confines of my own
application, which is a custom Linux boot disk for my project
(http://unattended.sourceforge.net/).  I am naming the directory
"glibc-20040306" or whatever and creating it using "co -D".

But it sure would be nice to just download the "latest release" from
ftp.gnu.org, like I can do for every other piece of free software, and
have some hope that it actually works.

 - Pat


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