[jp] build from cvs
David A. Desrosiers
hacker at gnu-designs.com
Thu Mar 6 14:32:18 EST 2003
-----BEGIN PGP SIGNED MESSAGE-----
> Be sure to make it _very clear_ that you must run autogen.sh ONLY when
> using a CVS checkout. Otherwise you/we will have tons of "bug reports"
> because autoconf/automake is not found, etc.
People who have enough courage and knowledge to use cvs, should be
knowledgable enough to know the processes used to build software from it,
including all of the required development packages they'll need to continue
to build it properly.
> - a normal user should use a pre-compiled package with correct
> dependency, etc.
> - an advanced user may use the tarball and recompile (after installing
> all the needed dev libraries).
> - a hacker may use the CVS version but he should know what he does.
> And a hacker should not have to read the INSTALL file to know what to
Absolutely not. The INSTALL file (or more likely, the ChangeLog) is
one of the most important bits of the source, whether it is from distributed
sources in a tarball or from CVS itself. There are also cases where INSTALL
when checked out from CVS is _NOT_ the same as INSTALL inside the release
tarball. If you don't read the docs before building the software, and you
have trouble, you deserve to feel the pain of errors.
Look at how many people build kernels in Linux from source, and look
at how many of those people read the CHANGES file _every_ time they upgrade.
I'd say less than 1% total. If you don't read the CHANGES file, you can
easily cause corruption, instability and crashes by not reading those docs.
I know this statistic to be true because I've dealt with it over the years
THOUSANDS of times trying to explain to people how to build kernels (which
is what prompted me to write my HOWTO on it).
This is only going to get worse during the transition between 2.4
and 2.5 kernels. These two kernels are NOT compatible, and the jump from one
to the other is not seamless. Lots of precautions have to be taken,
including installing some overlapping packages.
> I used to provide pre-compiled Debian packages from CVS version between
> 0.99.2 and 0.99.3 since the CVS version corrected bugs.
This is one _huge_ thing I object to (with my own packages,
specifically pilot-link). I've seen Red Hat and SuSE do checkouts of
post-release code of pilot-link, which fixes some bugs AND CAN INTRODUCE
The package maintainers distribute these, incorrectly thinking that
since it's later than the release version, it must be "better". If you use
cvs _anything_, you take your chances with it.
Red Hat in one case decided that releases weren't happening as fast
as they wanted, and they incremented the version number of _my_ code to the
next one in series (0.9.3 was an official release, 0.9.4 was NEVER an
official release, and if you search back, you'll see a LOT of people running
these rogue 0.9.4 packages of pilot-link, which never existed, except in
distributions). Red Hat bumped the version of pilot-link to 0.9.4, and
released it into the wild, so they could force people to upgrade to that
package, then it spread like wildfire, causing all kinds of problems. It is
for that exact reason that I skipped the 0.9.4 series and made 0.9.5 the
next release in that series.
Red Hat also put a cvs version of pilot-link into RH 7.2 when it was
released, which was 8 months OLDER than the official release, which fixed a
lot of bugs, and the one in 7.2 still had lots of unresolved issues in it
(because it was from cvs at a time 8 months before the official release).
As a maintainer of source which is used in this fashion, it gets
very frustrating to try to make sure we keep a nice solid (working) cvs, and
that these distributions play by OUR rules, not theirs.
I could just as easily lock out cvs entirely, except for people with
commit access, but I'm willing to not have to go that far just to keep the
distributions and distribution package maintainers in line.
> If your distribution does not provide good enough packages then change
> your distribution :-)
Good enough means functional, not bleeding edge, or "Every package
from cvs", in my opinions, and I'm sure the opinions of others.
That's my take on the issues you've presented.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the Jpilot