Skip site navigation (1)Skip section navigation (2)
Date:      15 Apr 1999 12:54:07 +0200
From:      Dag-Erling Smorgrav <des@flood.ping.uio.no>
To:        asami@FreeBSD.org (Satoshi - Ports Wraith - Asami)
Cc:        obrien@FreeBSD.org, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/share/mk Makefile
Message-ID:  <xzpiuayxigg.fsf@flood.ping.uio.no>
In-Reply-To: asami@FreeBSD.org's message of "Thu, 15 Apr 1999 02:38:11 -0700 (PDT)"
References:  <199904150719.AAA49596@freefall.freebsd.org> <xzplnfuxni2.fsf@flood.ping.uio.no> <199904150938.CAA62650@silvia.hip.berkeley.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
asami@FreeBSD.org (Satoshi - Ports Wraith - Asami) writes:
>  * From: Dag-Erling Smorgrav <des@flood.ping.uio.no>
> 
>  * IMHO, it's still completely bogus. The ports makefiles interpret the
>  * contents of port.mkversion as some kind of version number for the
>  * system makefiles, but all it actually tells you is when those files
>  * were last copied from one place to another. Hello, reality check? I
> 
> I'm tired of this.  There has been a long discussion on this already
> before it was added.  Please check the mail archives.

Yes. Your arguments of 'reducing the support load' are bogus, too. You
haven't reduced anything; you've at best changed the question they
ask, and at worst increased the support load significantly, because
your port.mkversion hack is unreliable to say the least and will
produce false negatives in numerous cases. Your obscene hack may
prevent a few users from shooting themselves in the foot (or from
submitting PRs because they can't distinguish a version mismatch from
a bug), but in many (most?) cases it just gratuitously breaks the
ports collection by producing false positives or false negatives. I'll
really laugh my (insert your favorite feature of anatomy) off if I
ever see a ports team member complain about people who have outdated
systems with an up-to-date port.mkversion because they ran make world
with old sources or rolled their own port.mkversion.

Adding -A to the fetch command line was bogus, too, for similar
reasons. I'd be very interested to know the exact percentage of ports
which fail (or may potentially fail) to build when fetch is invoked
without -A. Compare this to the percentage of ports which failed to
build on slightly-too-old systems after you added -A to the fetch
command line: 100%. Then explain to me why this is not 'optimizing for
the least common case'.

By the way, have you considered verifying the MD5 checksum during make
fetch, so that if the checksum fails, you move on to the next master
site instead of pretending you have a correct distfile and bailing out
later? This would make -A superfluous, and would allow ports-current
to work on 3.1-RELEASE.

The ports collection used to be really cool, but these days it just
not as much fun as it used to be. I'm very sorry to see you've chosen
quantity over quality. Yes, there is an impressive amount of ports in
the tree, but quality control is inexistant, and there is a growing
number of ports whose sole purpose seems to be to fill the quota. And
then there's this elitist attitude of gratuitiously refusing to work
on systems older than the latest Linux kernel-of-the-week...

DES
-- 
Dag-Erling Smorgrav - des@flood.ping.uio.no


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?xzpiuayxigg.fsf>