Re: Building glibc 2.0.7 using hamm
On Thu, 2 Apr 1998, Brian White wrote:
> > > 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"?
>
> I assume you meant "why _wouldn't_ it be a 'good idea'"?
Absolutely ;-)
>
> The problem is that the "more functional" means the creation of new bugs
> in addition to the fixing of some older ones.
I've heard this theory from you before, and I don't subscribe to the
automatic nature of this idea.
Adding a well defined feature with clearly understood code impacts creates
a narrow window for incorperating new bugs, but it also makes the
testing/vetting process for that code much clearer than with the complete
collection of code.
> If the changes from .10
> to .26 were bug-fixes only, there would be no problem.
Why is there some magical difference between new code inserted to fix a
known bug, and new code inserted to provide additional functionality
(like, for instance, an option to turn on, or off, some portion of
existing functionality)
Both activities are about equally likely create a different bug, and these
can usually be identified before releasing the package, and backed out.
> As soon as these
> release are steps along the development cycle, there is a large potential
> for problems.
>
All releases are "steps along the development cycle". They all have
potential for problems.
>
> > > 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.
>
> Hmmm... I don't suppose there is a flag that can be given to configure that
> will disable this feature?
>
It turned out to be an artifact of building the CVS archive. The
distribution tarball will have none of those subdirectories and will not
trigger the behavior (even with CVS installed). The info files are also
provided "pre-built" in the tarball, while they were not in the archive.
These two source dependencies will not be in the delivered source.
Luck,
Dwarf
--
_-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (850) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: dwarf@polaris.net Tallahassee, FL 32308
_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: