Re: Building glibc 2.0.7 using hamm
On Sun, 29 Mar 1998, Avery Pennarun wrote:
> On Sat, Mar 28, 1998 at 07:49:27PM -0500, Dale Scheetz wrote:
>
> > I now have the latest 2.0.7 pre-release version of glibc building packages
> > successfully. However, because several programs were necessary that are
> > not available in the distribution, glibc is currently, technically, a
> > non-free package (because the ability to rebuild the source depends on
> > packages outside of main).
>
> I thought that made it 'contrib'. At least, that's where ddd-[sd]motif
> ended up.
Essential packages, like libc6 can't leave main.
>
> > The two packages are cvs and tetex (actually it's makeinfo, but this
> > program is only found in the tetex packages).
>
> Neither of these should actually be needed to build the library itself --
While this is true, they are both involved in the building of the
packages.
> you might have to cheat a little in a Makefile or two, but given the LGPL
> that's easy and perfectly okay.
>
You seem to be worried about licenses, while I'm worried about
functionality. Other platforms must also be able to build packages like
glibc. This is an attempt to clean/clear up a cluttered path to a build.
> > CVS is currently released in Debian as version 1.9.10, while the version
> > that I used to retrieve and build glibc was 1.9.26.
>
> Now, I'm not The Amazing CVS Expert, but I do know that any version of CVS
> greater than 1.9 is an "interim release" which I think www.cyclic.com
> describes as "only slightly tested." Since the hamm freeze is in place and
> CVS 1.9.26 adds significant new features since 1.9.10 -- AND 1.9.10 works
> pretty well -- I personally don't think it's a good idea to change CVS
> versions at this point. Even using 1.9.10 makes me a little queasy, but I'm
> not the maintainer and it's been there a long time and it seems to work so I
> don't complain :)
As the point release numbers get larger 1.9 gets more bug free. Why would
moving to a more functional, less buggy release be a "good idea"?
>
> On that note, why are we using a prerelease of libc6? If it currently
Because it has fewer bugs than the previous 2.0.6 release. We are also
acting as beta test site for the release to help insure it has even fewer
bugs. (several math errors have been found by Debian developers, and fixed
in these pre-release versions of 2.0.7)
In addition, the release of 2.0.7 is certain, and soon. (Ulrich tells me
that when I report a functional library to him he is ready to make the
release {all other test sites are green})
> requires an unreleased version of CVS just to build (which is weird!) then
The 1.9.26 version has been released, and was obtained by me from a public
mirror site. It built right out of the box, with absolutely no problems.
The Debian version of 1.9.10 failed to retrieve the archive from the CVS
tree of glibc, while the 1.9.26 version retrieved it with no problems.
When building the packages, the Debian version of cvs was recognized, but
failed the tests presented by various make targets, while the, home built,
1.9.26 worked fine.
> it sounds like it has still has quite a few rough edges, and it worries me
> to base a distribution on it.
>
The current version of libc6 has far fewer "rough edges" than its 2.0.6
ancestor. The current "pre-release" version of 2.0.7 currently in frozen
is superior to the 2.0.6 release version. Why not base the distribution in
something better?
> Just out of curiosity, what on earth does libc6 _do_ during its build
> sequence that requires such a new CVS? When your C library requires a
> version control system just to compile, the chicken-and-egg problems start
> to get really confusing :)
>
It isn't required, but if you have it installed (as many do), the
configure step will recognize that it is there and configure the tests. I
guess that the assumption is that you may have made changes that will
need to be "checked in" at the end of the build process. The make files
and configuration process were designed by the upstream developers to
satisfy more than the needs of Debian. This is a side effect of that
additional functionallity.
> If you need the newest CVS only to pull glibc out of their repository, I
> don't think that really causes a problem. The rest of us can just download
> your source archive.
>
True enough but not useful. If cvs is installed in the build system (very
likely) then the glibc build will recoginze this fact and test it for full
functionality; a test our current version fails.
> Have fun,
>
Later,
Dwarf
--
Still sigless
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: