Subject: Re: make update hell
To: NetBSD Packages Technical Discussion List <tech-pkg@NetBSD.org>
From: Alistair Crooks <firstname.lastname@example.org>
Date: 10/15/2004 23:29:58
On Wed, Oct 13, 2004 at 03:54:55PM -0400, Greg A. Woods wrote:
> [ On Sunday, October 10, 2004 at 10:55:43 (+0100), Alistair Crooks wrote: ]
> > Subject: Re: make update hell
> > I am absolutely distraught that Greg's views are different from my own.
> It wouldn't be so bad if you had some logical argument to support your
> case and to try to dispute the logical arguments I've made.
> Brushing the issue under the rug is not a valid answer.
Oh, I wasn't trying to brush anything under the rug, but I was busy
this last week, which is why it's taken me 2 days to reply to your
mail that took 3 days to reply to mine. In fact, I've only just read
Looking at your "logical arguments" in
I find them to be curiously ... well, a non-sequitur. You declaim
that package views can only work properly for trivial packages because
of configuration file differences. Then you say that the fact that
non-trivial packages like emacs and gcc and even autoconf can exist in
a number of different versions without a depot-like scheme is proof
that no such scheme is needed, because authors will magically start
writing their software in multi-version-friendly ways. The
responsibility is to be placed on the shoulders of the authors of that
software. Well, call me cynical, but that ain't gonna happen.
There is software written out there whose authors will not take back
any changes that were proferred, who aren't interested in that kind of
thing, or who will just simply ignore you. They either don't like us,
have no intention of looking at our mail, or are dead. I'm sure there
are other reasons. The crusty-software-author problem exists, and
package views solves that problem. Passing the buck won't work.
I believe the packages you cite in your mail either have personalised
configuration files (like emacs), none (like autoconf), or need none
(like gcc, discounting spec files). This isn't proof, because you're
not attacking the root of the problem.
I won't deny that configuration files don't fit snugly into this
world, and that we've thought long and hard about them. But it also
means that we have to find a scheme which addresses this, which makes
them work, rather than throwing up our hands and shouting "Too hard!"
We have worked very hard in pkgsrc to keep package views as being
simply one option - the standard ("overwrite") installation type is
still there, and still supported, and I don't see that ever changing.
We have people who use pkgsrc for embedded environments, and for
installations where symlink farms are not wanted, necessary or